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data  objects  that  live  across  multiple  invocations  of  programs  that'  read  and 
modify  those  objects;  we  call  such  data  objects  “permanent  objects'*.  Typically, 
programmers  needing  to  save  data  objects  permanently  do  so  either  (1)  by 
writing  an  ad  hoc  set  of  procedures  that  convert  their  data  from  some  internal 
representation  to  some  external  vepresentation  (and  back),  or  (2)  by  inter¬ 
facing  their  programs  with  an  existing  database  system.  We  discuss  the— - 
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~f  problems  encountered  by  a  programmer  adopting  either  of  these  strategies,  and 
we  describe  our  system  whose  design  is  an  attempt  to  strike  a  balance  between 
the  flexibility  of  the  ad  hoc  approach  and  the  rigidity  of  the  approach  that 
employs  a  database. 

A  key  goal  of  our  work  is  the  design  and  implementatl on  of  a  system  that  makes 
the  manipulation  of  permanent  objects  nearly  as  easy  and  flexible  as  the  mani¬ 
pulation  of  "transient"  objects  -  i.e.  the  memory  resident  data  structures 
that  programmers  are  accustomed  to  dealing  with.  We  wish  to  hide  the  details 
associated  with  the  fact  that  permanent  objects  must  have  their  permanent  home 
in  a  disk  file  system. 

Our  system  is  written  in  T,  a  dialect  of  Scheme,  which  is  in  turn  a  dialect  of 
Lisp  and  runs  on  the  Apollo  workstation.  The  system  provides  tools  to  make  it 
relatively  easy  to  write  T  programs  that  manipulate  these  permanent  objects. 

A  secondary  goal  of  our  work  is  to  support  distributed  computing  by  allowing 
multiple  processors  to  have  access  to  permanent  objects.  While  the  system 
does  not  address  all  the  Issues  associated  with  distributed  computing,  we 
believe  that  the  mechanisms  provided  can  be  effectively  used  in  the  course  of 
solving  certain  problems  in  a  distributed  way. 
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Chapter  1 


Introduction 


Programmes*  are  often  confronted  with  the  problem  of  writing  programs  that  need  to  manipulate 
(create,  access,  modify,  delete)  permanent  objects  (data  structures).  By  “permanent  objects”  we 
mean  objects  that  live  longer  than  one  invocation  of  a  program.  These  objects  must  be  stored  in 
the  computer’s  file  system. 

Generally  the  capabilities  of  file  systems  and  the  tools  for  manipulating  file  systems  are  primitive. 
File  systems  present  only  the  simplest  of  data  typet  (e.g.  cne-dimensional  array  of  characters).  More 
compl-sc  data  structures  can  be  built  on  top  uf  these  simple  data  types,  but  the  implementation 
time  is  significant.  As  a  result,  a  programmer  is  not  inclined  to  thjuik  that  he  is  dealing  with  a 
permanent  object  when  be  really  is.  Be  simply  views  his  programs  as  reading  a  file,  constructing 
tome  transient  data  structures  in  main  memory,  reading  or  modifying  those  data  structures,  and 
possibly  rewriting  the  file  that  was  read  as  the  first  step.  The  programmer  is  not  ^tcouraged  to 
view  the  disk  file  merely  as  a  data  structure  in  another  guise.  Often  the  format  of  the  output  of  the 
program  is  designed  to  be  useful  for  human  read  jts  of  that  output  in  spile  of  the  fact  that  the  only 
person  who  h  likely  to  read  it  k  the  programmer  himself  while  debugging  his  programs. 

In  this  thesis  we  will  be  concerned  with  the  issues  of  creating,  modifying  and  administering  per¬ 
manent  objects  in  T  (-44,46],  a  dialect  of  Scheme  [S2],  which  a  in  turn  a  dialect  of  Lisp  (Sfij.  The 
goal  of  our  work  w  to  blur  tbs  distinction  between  permanent  and  non- permanent  objects;  i.e.  to 
make  the  writing  of  programs  that  manipulate  permanent  objects  nearly  as  easy  u  the  writing  of 
programs  that  manipulate  non-permanent  objects.  We  will  describe  the  design  and  implementation 
of  a  programming  system  that  allows  permanent  objects  to  be  accessed  using  primitives  that  are 
analogous  to  the  primitives  used  to  access  non- permanent  objects.  The  system  we  will  describe  has 
been  built  and  used  for  non- trivial  applications. 

The  work  described  in  this  thesis  differs  from  previous  work  in  permanent  objects  in  that  it  supports 
a  potentially  very  large  set  of  objects  of  both  snail  and  large  size,  and  it  allows  these  objects  to  be 
accessed  by  different  users  and  application  programs. 


1.1  An  example 


Consider  a  user’s  electronic  mail  box.  Within  a  program  that  manipulates  a  mail  box  there  is  %  mail 
box  data  structure  that  might  consist  of  a  linked  List  of  mail  message  objects.  Each  mail  message 
might  consist  of;  a  string  containing  the  text  of  the  message;  tome  boolean  flags  indicating,  for 
example,  whether  the  message  has  been  read  by  the  user;  a  pointer  into  the  text  of  the  message 
where  the  message  headers  begin;  and  a  pointer  into  the  text  of  the  message  where  the  message 
body  begins. 

The  mail  box  is  of  interest  to  at  least  two  programs:  a  mail  user  interface  program  that  lets  &  usei 
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read  stnd  modi?;  the  cod!, cats  of  his  mail  box;  tad  a  mail  delivery  program  that  adds  new,  incoming 
mail  to  iho  mail  box.  TL-sse  pro-gram*  may  be  invoked  multiple  times  to  manipulate  the  mail  box. 
The  m^dl  box  cxbta  independently  of  the  program*  that  areas*  it. 

A  typical  implementation  strategy  taken  by  a  programmer  (e.g.  aa  in  02  (IS],  a  mail  user  interface 
for  the  DEC3Y3TTM-20)  who  does  not  view  a  maii  box  as  a  permanent  object  hi  this:  the  mail 
i~~.r  l.;?s ;'cce  tvM  in  a  text  die  that  contains  ail  tie  user’*  mesatagts.  Tie  program  break®  the 
Hi  Lb©  k dividual  maattjia.  Depending  on  the  conventions  of  tie  mail  system,  the  mas&cgss  may 
be  separated  by  some  sequence  of  character*  that  are  guaranteed  not  to  appear  in  the  text  of  a 
ict-ip;  or  c-uch  r&eina^s  may  be  preceded  by  a  text  siring  of  dibits  which  when  interpreted  as  an 
iatsyer  specif  a®  the  kngth  in  bytes  of  tie  mesit  y»  that  follows.  Once  broken  up  into  individual 
rr.-eem. jea,  the  program  allocates  object®  to  bold  the  merges  and  links  the  meesr^es  together  to 
form  the  entire  mail  box  data  structure  a®  described  above.  Perhaps  the  first  !L»;  of  each  message 
contains  a  string  of  one®  and  aero®  indicating  the  value*  cf  the  various  message  flap.  This  string 
will  have  to  be  parsed  into  boolean  values  and  stored  in  tie  appropriate  slot®  in  the  messing*  data 
structure. 

The  i:ccr  inter  free  program  manipulate®  the  mail  box  object  in  reopen*  to  in:cr  commands.  When 
the  :t  exits  program,  the  program  re-write®  the  tort  file  to  reflect  the  a«w  state  of  the  mail 
box.  This  procedure  centhts  cf  inverting  the  mail  box  data  structure  and  writing  its  contents  in 
the  format  expected  by  all  pro  •{mas  that  manipulate  the  mail  box  file. 

The  moot  serious  problem  with  this  approach  b  the  cost  of  parsing  the  file  on  pro-gram  startup  and 
fonr.  tiring  the  file  on  program  termination,  especially  as  the  rise  cf  the  r-oil  box  increases.  Our 
y. 'll  i.i  to  dmacarinte  that,  given  tbs  right  tools,  the  programmer  u®  taink  of  something  like  a 
mail  box  ra  a  permanent  object  end  that  as  a  result,  programs  that  manipulate  the  object  can  be 
simpler  to  write  and  more  e-iciant  in  execution. 
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>nal  approach  eo 


Tiwre  are  at  Semst  two  tradition*]  appro-ache*  for  dealing  with  permanent  object®.  For  studying 
both  thew  approach®*,  it  will  be  convenient  to  think  of  the  objects  aa  having  two  .^presentations: 
internal  and  external.  The  internal  representation  i®  *he  format  of  the  data  structure  when  it  reside® 
in  m  •:  in  memory;  the  external  representation  is  the  format  of  the  data  structure  when  it  resides  in 
stable  store  .je  («.g.  di.tk  files  in  a  conventional  file  system). 

The  Hr.'X  rpproach  consists  of  writing  an  ad  hoc  set  of  subroutines  that  convert  from  the  internal 
roprr.wnts.tio3  to  the  external  representation  and  set  of  routines  that  do  the  revenre  conversion. 
TLa  approach  is  marginally  better  than  the  one  taken  to  solve  the  mail  box  problem  above. 


Tlie  s-:-coid  approach  is  to  inttrfeca  the  application  program  that  needs  to  use  permanent  data 
ttmcturw  with  aa  existing  ‘database  manager.*  We  use  the  term  ‘database  manager*  in  a  •eery 
"moral  way  to  .mn  a  set  of  programs  or  subroutines  that  hove  been  dev:  pa  id  to  store  and  retrieve 


data  from  a  tile  system. 

la  ca.’ses  where  the  internal  representation  b  simple  (e.g  a  character  string  or  a  vector  of  iste- 
C-tn),  the  temptation  b  great  for  a  programmer  to  use  the  ad  hoc  solution.  Hs  says:  *1  don’t 
want  to  yet  involved  with  the  complexity  of  such-and-such  database  system.  PIS  just  write  ir.y 
stria ga/numbers/etc.  out  to  a  simple  text  file."  Unfortunately,  tlii®  seductive  reasoning  results  in 
a  program  that  b  not  only  not  a®  fast  as  it  mi^hi  be  (due  to  the  representation  conversions),  but 
one  that  b  also  bard  to  modify  and  hard  to  extend.  Having  implemented  one  ad  hoc  solution,  the 
programmer  b  unlikely  to  want  to  implement  another  one  (or  modify  the  existing  one)  in  order  to 
accomodate  Increased  functionality.  As  a  recult,  the  functionality  does  not  get  implemented. 


What  are  the  argument*  ia  favor  of  uring  an  existing  database  manager?  A  clear  advantage  b  that 
much  of  the  programr-ir's  work  b  already  done  for  him  by  the  database  manager.  The  programmer 
need  not  be  concerned  with  the  details  of  the  file  system.  Most  sophisticated  database  systems  offer 
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some  degree  01  reliability  in  the  face  of  hardware  failure.  Database  manages*  take  care  of  storage 
allocation. 

Unfortunately,  interfacing  to  a  database  manager  may  introduce  some  problems.  The  program 
interface  to  the  database  manager  forms  an  ‘embedded  Language.*  That  is,  the  set  of  calls  by 
which  the  application  program  accesses  data  maintained  by  the  database  manager  is  a  language  of 
its  own.  This  language  is  built  on  top  of  the  language  in  which  the  calls  to  the  database  manager 
are  written.  As  a  result,  the  programmer  is  no  longer  programming  using  solely  the  primitives  of 
the  base  programming  language.  In  fact,  the  primitives  of  the  base  programming  language  may 
not  even  be  applicable  to  the  application’s  data,  which  now  resides  in  the  world  of  the  database 
manager. 

Thus,  taking  the  database  approach  to  solving  the  permanent  object  prob1em  obliges  the  program¬ 
mer  to  work  in  two  languages;  the  base  language  and  the  database  embedded  language.  Often  this 
complexity  is  great  enough  to  dissuade  the  programmer  of  a  medium-size  application  from  using 
the  database  manager. 

Creating  and  bring  embedded  systems  is  not  always  bad.  In  most  large  programming  projects  one 
ends  up  constructing  and  using  some  sort  of  embedded  language.  Some  languages  support  such 
embedding  better  than  others  (e.g.  Lisp  system*  generally  have  a  powerful  macro  facility).  Even 
in  languages  that  do  not  allow  modification  to  their  syntax,  the  subroutines  that  the  programmer 
defines  for  use  by  himself,  but  especially  for  use  by  other  programmer*  working  on  the  same  project, 
define  the  semantics  of  a  language.  When  a  programming  project  adopt*  a  set  of  conventions  and 
interfaces  that  make  up  the  specification  of  an  embedded  language,  the  comprehensibility  of  the 
overall  project  increases;  functionality  can  be  expressed  in  terms  of  the  embedded  language  instead 
of  in  terms  of  the  base  language. 

There  is  a  key  difference  between  embeddings  such  as  the  ones  that  go  on  all  the  time  and  the 
embedding  of  a  large  database  system.  In  the  former  case,  the  programmers  in  the  project  design 
the  embedded  system  themselves,  to  their  own  specifications.  In  the  latter  case,  the  embedded 
language  is  typically  not  under  the  control  of  the  project  that  uses  the  database.  As  a  result, 
the  programmer  may  be  forced  to  use  an  embedded  language  that  is  not  at  all  appropriate  to  his 
application. 

A  significant  limitation  of  both  the  ad  hoc  and  the  database  approach  to  storing  permanent  data 
is  that  they  are  unable  to  deal  with  pointer*.  By  “pointer*  *v  mean  the  traditional  programming 
language  construct  that  allows  indirect  reference  to  data.  Since  pointers  are  convenient  tools  for 
the  programmer,  it  is  undesLable  that  they  should  be  unavailable  wBcs  storing  permanent  objects. 

The  limitations  of  the  traditional  approaches  outlined  above  become  clear  when  dealing  with  even 
simple  data  structures.  For  example,  Lisp  has  a  primitive  procedure  called  map  that  applies  a 
procedure  to  a  linked  list  of  objects.  Lists  are  easy  to  create  and  map,  and  other  procedures  provide 
a  dean  and  convenient  mechanism  for  accessing  the  data  in  the  list.  Use  of  lists  in  Lisp  programs 
is  pervasive;  use  of  lists  In  external  representations  is  unusual. 

If  the  linked  list  is  maintained  within  Joe  database  manager,  two  problems  can  arise.  The  first 
problem  is  that  the  database  manager  might  not  expert  references  to  the  middle  of  a  linked  list. 
That  it,  the  database  manager  might  export  references  to  individual  data  items,  but  not  to  data 
structures  that  it  view*  a*  being  internal  to  the  database  system.  As  a  result,  tnere  is  no  reference 
that  can  be  purned  as  the  procedural  argument  to  map. 

A  second  problem  that  can  arise  is  that  even  if  the  application  can  obtain  a  reference,  the  list  that 
U  constructed  and  maintained  by  the  database  manager  might  not  be  manipulatable  by  map  (and 
the  elements  of  the  list  by  the  procedural  argument  to  map)  because  of  differences  between  the 
representation  maintained  by  the  database  manager  and  the  representation  expected  by  the  Lisp 
system.  The  coat  of  this  representation  conversion  is  unacceptably  high.  In  the  permanent  object 
system  we  built,  representation  conversion  is  not  necessary. 

The  goal  of  the  work  described  in  this  thesis  is  to  develop  a  system  for  managing  permanent  objects 
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th;t  is  mcr;  general  than  the  ad  hoc  methods  bat  Ism  cumbersome  than  the  methods  that  require 
interfacing  to  a  database  system. 
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local  network.  Recently,  much  research  has  beta  concerned  with  the  problem  of  being  able  to  take 
advantage  01  .he  newly  available  small  pracarscra  (e.f.  the  Motorola  6SCC0)  configured  in  a  network 
in  order  to  make  applications  run  fester  or  more  reliably.  Much  of  this  research  has  addressed 
concurrency  problems:  if  there  are  multiple  processes  running  on  multiple  processors  accessing  the 
same  data  (or  replicated  copies  of  the  data),  how  do  you  coordinate  their  activity  to  insure  the 
integrity  of  the  data? 


Before  one  can  ad  dr  era  the  L-aue*  in  controlling  concurrent  access  to  data,  it  is  first  necessary  to 
concider  the  problems  in  simply  accessing  the  data.  The  issue  of  making  the  data  available  to  the 
multiple  processes  bes  been  discussed  elsewhere,  but  aot  to  the  level  of  detail  necessary  to  illuminate 
the  hard  problem  that  arise  in  ».  real  implementation. 


Though  distributed  computing  is  aot  the  main  topic  of  our  work,  we  designed  our  permanent 
obj-rct  system  end  built  cur  implementation  in  a  way  that  docs  not  preclude  the  later  introduction 
of  sophisticated  concurrency  control  mechanism*.  Our  current  implementation  fcaa  rather  couree- 
grainsd  concurrency  control.  However,  even  this  level  of  control  is  useful  for  distributed  applications 
where  concurrency  is  low  -  i.e.  where  convicting  requests  for  access  to  data  occur  infrequently.  For 
example,  the  applications  in  our  mail  system  example  -  the  mail  user  interface  and  the  mail  deliverer 
-  ere  examples  of  applications  that  might  be  distributed  among  a  number  of  proeeaora.  La  this  case 
the  expected  degree  of  concurrency  is  low,  and  simple  concurrency  control  technique*  (e.g.  waiting 
for  a  file  to  become  unlocked)  are  sufficient  to  solve  Uie  piobiem. 


1.4  Applications 

A  perm?  seat  object  system  has  many  potential  applications  in  addition  to  the  mail  system  example 
given  above.  We  list  some  applications  that  deal  with  permanent  data,  describe  existing  implemen¬ 
tations,  and  deseibe  how  a  general  permanent  object  system  could  be  uaed  in  an  implementation. 

•  Compiler  auxiliary  files. 

The  T  compiler  produces  a  r*pp«t  <  file  that  contains  all  the  macro  and  constant  definitions  in  the 
module  being  compiled.  The  support  file  can  be  referenced  in  other  files  so  that  when  those  files 
are  compiled,  the  information  from  the  supnert  file  can  be  used  to  produce  more  efficient  code. 
Presently  in  T,  support  files  rue  text  file*  containing  printed  T  exprwsnons.  The  compiler  must 
read  and  parse  the  entire  rapport  file  when  it  is  referenced  from  the  file  being  compiled.  Using  a 
permanent  object  system,  the  data  structures  describing  the  macro  sad  constants  definitions  coaid 
be  permanent  objects  and  accessed  more  quickly.  We  could  lake  this  path  further  and  replace  source 
text  files  themselves  with  permanent  objects  describing  the  program  source. 

•  Text  formatter  database. 

The- Seri  be  document  preparation  system  [47]  uses  a  set  of  database  files  describing  output  devices, 
document  formats,  and  bibliographies.  These  files  contain  text  string  Scribe  commands.  When  a 
reference  is  made  to  a  particular  device,  document  format,  or  bibliography  from  a  document  being 
formatted,  Scribe  must  linearly  scan  one  or  more  of  the  document  text  files.  This  scan  can  be 
very  expensive,  especially  in  the  case  of  large  bibliographies.  Using  a  permanent  object  system,  the 
database  could  be  represented  as  a  set  of  permanent  objects  and  accessed  more  efficiently. 
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•  Registry  of  turn. 

The  Unix  { 13]  system  for  registering  users  is  s  text  file  containing  one  line  for  each  user.  Each 
line  contains  (among  other  things)  a  user  ID,  password,  and  full  name.  Any  applications  that  need 
the  informatics  must  read  and  parse  the  text  file.  Mechanisms  to  control  concurrent  access  to  the 
registry  would  be  useful  but  are  non-existent,  hence  exposing  the  system  to  data  corruption.  The 
file  has  a  rigid  format  and  the  presence  of  programs  that  rely  on  the  format  makes  it  difficult  to 
extend  the  registry  to  hold  new  kinds  of  information  about  users,  lut  rigidity  is  partially  a  result 
of  the  ad  hoc  way  the  data  is  stored  and  accessed.  Using  a  permanent  object  system,  each  user 
could  be  represented  as  a  permanent  object  and  the  entire  registry  as  a  permanent  collection  of 
those  objects.  The  objects  could  be  designed  to  allow  both  extensibility  of  information  about  users 
and  concurrency  down  to  the  individual  user  level. 

•  On-line  help  systems. 

The  on-line  help  system  used  on  the  DECSYSTEM-2Q  at  the  Yale  Department  of  Computer  Science 
consists  of  a  text  file  (called  the  index  file)  that  contains  a  list  of  indices  (words)  and  help  file  names. 
Users  query  the  system  using  an  index  and  the  system  responds  by  offering  to  display  the  contents 
of  the  help  files  associated  with  that  index.  Whenever  the  index  file  is  modified  (by  a  help  system 
administrator),  a  binary  fiie  must  be  produced  (by  running  a  special  program  that  converts  the 
index  text  file  text  to  an  index  binary  file).  The  format  of  the  text  file  is  designed  to  simplify  the 
administrator's  job.  The  format  of  the  binary  file  is  designed  to  make  the  help  system  programs  run 
efficiently.  Using  a  permanent  object  system,  there  would  be  no  need  to  have  two  representations 
(text  and  binary)  of  the  index  file.  The  index  could  be  a  permanent  object  that  could  be  accessed 
both  by  the  help  system  programs  in  response  to  users’  queries  and  by  help  system  administrators 
to  change  the  contents  of  the  index. 

All  of  these  applications  involve  permanent,  structured  data  that  must  be  changed  in  a  controlled 
way.  Many  existing  implementations  of  such  applications  use  inefficient  techniques  (such  ns  those 
that  require  unnecessary  parting  and  formatting  of  data)  or  on  general  mechanisms  designed  for 
a  single  application.  An  efficient,  general,  and  simple  object  management  system  will  improve  the 
performance  of  such  applications  and  encourage  programmers  to  write  more  such  useful  applications. 

1.5  Outline  of  the  rest  of  the  thesis 

The  focus  of  this  thesis  is  a  system  we  call  OM,  a  system  for  managing  permanent  objects.  We 
designed  and  implemented  a  running  version  of  OM.  We  also  designed  and  implemented  two  sample 
applications  systems  that  run  using  the  facilities  provided  by  OM. 

Chapter  2  coven  the  problems  associated  with  building  a  system  that  meets  the  goals  described 
above.  Chapter  S  discusses  the  implementation  of  OM.  Chapter  4  discusses  how  programmers  write 
application  programs  using  OM;  in  this  chapter  we  also  describe  the  sample  application  programs 
we  built.  Chapter  5  summarises  OM  and  discusses  bow  well  it  solves  the  problems  raised  in  chapter 
2. 
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la  this  chapter,  we  outlia-i  some  cf  the  problems  faced  by  a  system  that  maintains  permanent 
objects*  Cur  basic  mode!  fer  the  computing  environment  La  which  permanent  objects  are  maintained 
b  traditional:  we  assume  a  CPU  with  a  fast  main  memory  of  limited  site  and  a  larger,  slower  disk 
memory.  Data  a  transferred  back  and  forth  between  disk  and  main  memory  in  relatively  large  units 
(compared  to  the  smallest  units  the  CPU  c&a  deal  with)  and  at  a  relatively  slow  rate  (compared  to 
the  rate  at  which  the  CPU  can  access  main  memory). 


2.1  P2rra.a13.2nt  data 


Many  of  the  problems,  that  arbe  from  wanting  to  preserve  objects  result  from  the  fact  that  since 
objects  can  be  manipulated  only  within  main  memory  and  since  main  memory  can  not  hold  all  the 
permanent  objects,  there  seeds  to  be  a  controlled,  reliable  mechanism  for  moving  data  in  and  out  of 
main  memory.  The  experience  gained  in  designing  virtual  memory  and  database  systems  is  relevant 
to  the  understanding  sad  the  solving  of  these  problems.  A  permanent  object  system  of  the  sort 
we’ve  outlined  can  use  techniques  from  both  virtual  memory  systems  and  database  systems.  Virtual 
memory  systems  provide  a  model  vf  how  to  refer  to  objects  that  are  “not  really  there*.  Databao* 
systems  oner  examples  of  how  to  deal  with  the  permanence  ia&u«s. 

We  will  due  ore  the  following  topics  in  permanent  data: 


•  Integrity  and  atomicity 

•  Abstraction 

•  Storage  control 

•  Sharing  and  concurrency 

•  Security 

•  Reliability 

•  Performance 


In  our  discussion  of  these  problems,  we  will  be  giving  each  problem  only  a  short  characterisation. 
The  orientation  will  be  very  practical  since  we  are  interested  in  bow  they  relate  to  the  system  we 
have  actually  built.  In  designing  this  system  we  have  tried  to  be  practical  so  that  the  the  system 
could  he  actually  built.  Later,  we  will  discuss  how  our  system  addresses  these  problems. 
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2.1.1  Integrity  end  atomicity 

By  inUfritf  we  steal i  the  functionality  that  insure*  that  the  permanently  preserved  data  is  not 
corrupted.  What  are  the  major  potential  source*  for  such  corruption? 

The  most  obvious  source  of  corruption  is  a  machine  crash.  (In  addition  to  actual  machine  crashes, 
abnormal  termination  of  individual  processes  or  failure  of  pieces  of  hardware  (e.g.  disk  or  network 
communication  hardware)  can  cause  problems  similar  to  a  crash.)  Some  of  the  permanent  data 
may  have  been  in  the  main  memory  of  the  crashed  machine.  If  the  main  memory  copy  of  the  data 
contained  changes  that  were  not  yet  reflected  in  the  copy  of  the  data  maintained  in  stable  storage, 
then  applications  that  use  the  data  could  be  in  trouble. 

For  example,  suppose  some  large  data  structure  is  being  modified  when  a  crash  occurs  and  also 
suppose  that  only  part  of  the  modified  structure  has  been  rewritten  to  stable  storage  before  the 
crash.  Assume  that  parts  of  the  data  structure  contain  related  information  -  e.g.  a  string  of 
characters  and  an  integer  indicating  the  length  of  the  string.  Suppose  the  part  of  the  data  structure 
containing  the  integer  length  got  written  to  stable  storage  but  the  part  containing  the  characters  of 
the  string  did  not.  Then  an  application  program  that  accesses  that  string  might  secern  too  few  or 
too  many  characters.  (In  the  latter  case  it  would  presumably  see  “garbage*.) 

Another  source  of  corruption  is  program  error.  In  the  course  of  application  program  debugging 
(or  later  when  some  unforeseen  bug  arises  in  production  use  of  the  application)  the  application 
might  present  some  logically  inconsistent  pieces  of  data  for  permanent  storage.  The  problem  here 
is  in  defining  what  “logically  consistent*  means.  If  the  permanent  data  storage  system  is  to  reject 
certain  pioces  of  input  then  the  consistency  rules  must  be  specified  and  be  part  of  the  system. 
Unfortunately,  the  specification  of  the  data  consistency  rules  may  be  non- trivial  (ar»d  a  task  in 
which  the  programmer  may  be  unwilling  to  engage).  In  addition,  if  the  data  storage  system  is  to 
be  relatively  simple,  modular,  and  efficient,  it  may  not  be  easy  for  it  to  maintain  the  set  of  rules  for 
a  large  set  of  applications. 

The  traditional  approach  to  maintaining  integrity  of  permanent  data  is  to  use  techniques  which 
guarantee  the  stsmicitf  of  a  set  of  changes  to  data.  Atomicity  is  a  property  that  implies  that  if 
any  of  a  set  of  changes  are  mad*  (i.e.  made  to  the  permanent  copy  of  the  data  in  stable  storage), 
they  all  are  made.  If  for  some  reason  the  system  fails  in  the  middle  of  a  set  of  changes,  the 
system  guarantees  that  it  appears  that  none  of  the  changes  have  been  made.  There  are  various 
implementation  techniques  that  can  be  employed  to  assure  atomicity  when  requested.  As  will 
become  apparent  later,  these  techniques  are  not  easily  applicable  to  tbs  system  we  design.  This  is  a 
ILnitation  of  our  current  system,  but  since  our  goal  is  to  gain  experienct  with  a  real  permanent  object 
maintainance  system,  we  are  willing  to  tolerate  the  potential  for  loss  of  integrity  for  experimental 
purposes. 


2.1.2  Abstraction 

It  should  be  the  goal  of  any  data  storage  system  to  provide  some  level  of  abstraction.  For  our 
purposes,  an  abstraction  is  a  mechanism  that  does  two  things: 

•  It  translates  logical  references  to  data  into  physical  references  to  the  data  itself. 

•  It  hides  details  of  the  representation  of  the  data  (eg.  how  many  bits  are  allocated  to  what) 
from  the  programmer. 

By  logical  reference,  we  mean  the  name  of  a  field  in  a  structure  or  a  key  into  a  table  mapping  logical 
references  into  physical  references.  “Physical  reference*  is  a  relative  term.  What  we  really  mean  is 
“let-t  logical  reference*.  That  is,  in  a  sys,  m  that  presents  layers  of  abstraction,  only  the  bottom 
layer  can  be  considered  to  be  addressed  by  physical  references  (e.g.  physical  main  memory  address 
or  disk  block  address).  Each  software  layer  above  the  bottom  layer  uses  references  that  are  logical 
with  respect  to  references  used  in  the  layer  below.  If  layer  A  is  below  layer  B,  a  major  function 
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cf  layer  A  b  to  translate  layer  B’a  logical  reference*  into  layer  A's  I-rse  logical  (i.«.  mors  physical) 
references. 


For  example,  at  one  layer,  a  reference  might  be  a  person’s  hat  name  represented  at  a  string; 

this  reference  mi-ht  be  p  m:  :d  to  a  lower  layer  that  Is  supposed  to  dltplay  informatics  about  the 


t*' v~£ -Ia  T5  't, a j.1  l1  ^  it 

Sdoctinew.  TLb  layer  mi. 

layer  maps  ice  integer  id 
the  object  resiles.  Tb.lt ! 


&-er  layer  La  turn  maintaias  a  taV.e  sen  oping  tilings  into  iatt-ger  object 
bt  deal  with  references  to  objects  other  th&a  peso’s;  La.  it  1?  a  layer  with 
r  layers  that  all  call  the  lower  layer  with  strings  as  refcresess.  A  still  lower 
adder  into  seme  disk  address  that  kckstia  whore  the  information  about 
‘.yer  too  might  have  multiple  immediate  higher  layers. 


The  overall  problem  of  choosing  the  form  cf  references  sad  designing  the  translation  mechanism  is 
critical  in  any  data  storage  system;  our  approaches  will  be  discussed  later. 


Another  role  of  abstraction  is  to  hide  the  representation  sad  impkuwatation  of  a  data  structure  in 
one  part  of  a  system  from  another  part  cf  the  same  system.  The  purpoee  of  this  sort  of  abstraction 

is  to  (hopefully)  allow  changes  to  the  representation  or  hapleraeatatioa  to  be  made  without  having 
to  scour  the  entire  system  lor  places  where  a  programmer  ban  'cheated*  by  employing  seme  pi-see 


tf  inf 


on  about 


data  structure  which,  by  the  “official*  specification  of  the  interface  with 


which  be  »  supposed  to  work,  he  is  not  entitled  to  employ. 


For  example,  suppose  acme  module  of  a  system  chooses  to  implement  sets  as  linked  lists;  this  module 
exports  subroutines  that  manipulate  sets,  but  it  does  not  “reveal*  that  sets  are  actually  lists.  If  the 
client  of  the  module  always  uses  the  subroutines  provided  by  the  set  module,  the  client  is  aaa&ected 
if  the  art  module  b  changed  to  represent  sets  a a  bit  vectors.  If,  however,  the  client  does  rely  on  the 
fact  that  eeta  are  implemented  as  linked  lists,  he  violates  the  set  abstraction  and  hence  when  the 
implementation  of  that  abstraction  changes,  the  client  breaks. 


2.1.3  Storaga  centre! 

A  system  that  maintains  data  permanently  must  deal  with  the  issue  of  controlling  the  allocation 
of  storage  occupied  by  the  data.  The  system  must  be  able  to  allocate  blocks  of  storage  of  varying 
sites  and  it  must  be  able  to  know  when  storage  occupied  by  data  baa  beco.vw  “free*  -  available  for 
allocation  to  another  piece  of  data. 

The  literature  is  full  of  techniques  for  allocating  storage.  (Knuth’s  work  jdO]  'a  a  standard  reference 
for  these  techniques.)  Some  techniques  require  that  data  stomps  be  explidty  fused  by  the  application 
that  owns  the  data  occupying  the  storage.  An  alternative  technique  is  ftrtagt  eottution.  Garbage 
collection  is  a  process  that  separates  the  space  of  objects  into  garbage  and  non-garbage.  An  object 
is  garbage  if  there  is  no  way  to  obtain  a  reference  to  the  object;  otherwise  the  object  is  non-garbage. 
The  literature  contains  many  descriptions  of  garbage  collection  techniques.  (Cohen’s  survey  [15] 
contains  an  excellent  summary  of  these  techniques.) 

The  main  advantages  of  using  a  storage  control  policy  that  relies  on  garbage  collection  are: 

•  Allocation  can  typically  be  done  very  quickly. 

•  There  is  no  dangling  reference  problem. 

In  a  garbage  collection  baaed  storage  system,  storage  can  be  allocated  out  of  a  monolithic  heap 
(i.e.  a  storage  pool  with  no  internal  structure).  The  state  of  the  storage  pool  consists  of  an  index 
(called  a  Aeap  pointer)  into  the  heap.  The  allocation  procedure  consists  simply  of  advancing  the 
heap  pointer  by  the  number  of  storage  units  requested  by  the  caller  and  then  returning  the  old  heap 
pointer  to  the  caller.  Such  a  procedure  can  be  implemented  in  a  few  machine  instructions  and  hence 
can  be  open-coded,  avoiding  the  cost  of  a  procedure  call  to  the  allocation  procedure.  •  r 

In  storage  systems  that  are  not  based  on  garbage  collection  and  hence  rely  on  the  explicit  freeing  of 
storage,  the  dangling  reference  problem  can  arise.  A  dangling  reference  is  a  reference  from  one  data 
structure  to  another  where  the  reference  is  to  a  piece  cf  storage  that  has  been  previously  explicitly 
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freed.  This  k  s  problem  once  the  freed  storage  may  be  reallocated  to  some  sew  data  structure  and 
the  dangling  reference  would  thee  refer  to  something  other  than  it  k  supposed  to.  In  a  garbage 
collection  based  system,  since  there  k  no  explicit  free  operation,  there  k  no  way  for  a  reference  to  be 
Wangling  The  garbage  collection  procedure  k  defined  in  such  a  way  that  any  reference  to  a  object 
ensures  that  the  data  object  will  not  be  freed. 

However,  there  k  a  serious  drawback  to  depending  on  garbage  collection.  While  it  at  first  appears 
that  allocation  k  cheap,  to  be  fair  one  has  to  the  factor  in  the  cost  of  the  garbage  collection.  Such 
a  factoring  produces  a  more  accurate  cost  of  the  allocation  operation.  Also,  in  traditional  garbage 
collectors,  while  the  garbage  collector  k  running,  no  other  part  of  the  program  can  run.  If  garbage 
collection  takes  a  long  time  and  it  occurs  frequently  enough,  this  time  can  be  intolerable.  However, 
recent  work  in  incremental  and  parallel  garbage  collecting  strategies  lessen  some  of  the  pain  garbage 
collection  causes  [11,18.1,26,27]. 

2.1.4  Sharing  asd  concurrency 

By  the  ability  to  share  objects  we  mean  that  nothing  about  an  object  restricts  it  to  being  used  by 
one  user,  or  one  application  program,  or  one  process. 

When  we  say  a  set  of  processes  run  concurrently,  we  mean  that  all  the  processes  are  active  and 
runnable  over  some  period  of  time.  By  concurrent  access  to  objects  we  mean  access  to  objects  by 
concurrent  processes.  We  will  use  the  term  eesesrmwf  to  maaa  the  measure  of  concurrent  access  to 
objects.  The  degree  of  concurrency  k  determined  by  how  many  processes  are  competing  for  access 
to  a  set  of  objects  over  how  long  a  period  of  time.  We  say  there  k  a  high  degree  of  concurrency  if 
a  large  number  of  processes  want  access  to  a  similar  set  of  objects  over  a  short  period  of  time.  We 
say  there  k  a  low  degree  of  concurrency  if  a  small  number  of  processes  want  access  to  a  similar  set 
of  objects  over  a  long  period  of  time. 

A  system  tha.  supports  sharing  need  not  necoaurily  support  a  high  degree  of  concurrency.  Enabling 
concurrency  does  require  that  the  problems  of  sharing  have  been  solved. 

Let  us  first  consider  the  problems  related  to  sharing  per  se.  The  main  problem  here  k  that  sJl 
information  about  an  object  must  be  accessible  from  a  reference  to  the  object.  No  information 
about  the  object  can  be  encoded  in  procedures  that  are  known  only  to  some  user  or  application 
program.  Also,  the  format  of  references  to  objects  (section  2.2  discusses  the  issue  of  reference  format 
in  detail)  must  not  rely  on  a  particular  user’s  or  application’s  context. 

For  concurrent  sharing,  let  us  first  consider  multiple  processes  sharing  a  single  main  memory.  We 
assume  for  reasons  of  correctness  and  efficiency  that  the  system  should  allow  just  one  copy  of  a 
particular  object  in  main  memory  no  matter  how  many  processes  are  sharing  that  object.  The  im¬ 
plementation  of  sharing  depends  on  the  lower  level  memory  architecture  of  the  underlying  operating 
system.  On  operating  systems  that  do  not  support  virtual  memory,  the  implementation  k  easy: 
translate  identical  references  from  different  processes  to  the  same  object  into  the  same  address  in 
physical  memory  where  the  object  has  been  read. 

Operating  systems  with  virtual  memory  support  come  in  two  varieties:  (1)  ones  in  which  all  proce&aes 
run  in  the  tame  virtual  address  space  (which  k  larger  than  the  amount  of  physical  memory  on  the 
machine);  (2)  ones  in  which  each  process  runs  in  its  own  separate  virtual  address  space.  In  case  (I) 
the  implementation  of  sharing  k  the  same  as  in  a  system  without  virtual  memory. 

In  order  to  be  able  to  implement  the  sharing  of  objects  in  case  (2),  the  system  must  support 
primitives  that  allow  the  manipulation  of  the  process  page  map.  That  k,  it  must  be  possible  to 
arrange  the  page  map  of  two  processes  so  that  references  to  some  set  of  virtual  addressee  in  one 
process  produce  the  same  values  as  references  to  a  possibly  different  set  of -addresses  in  another 
process.  Given  these  primitives,  the  system  can  arrange  that  there  k  one  copy  of  the  object  in  main 
memory  sod  that  all  references  to  it  from  all  processes  point  to  the  single  copy  of  the  object. 

Given  tbs  ability  to  manage  processes  state  and  main  memory  as  described  above,  concurrent  read 
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access  to  objects  presents  no  particular  problems.  The  real  problems  of  sharing  arise  when  other 
(1)  one  or  more  processes  want  to  be  able  to  modify,  act  just  rati  the  data;  or  (2)  multiple  processes 
wishing  to  read  or  modify  the  data  do  not  share  a  ccsxrson  sain  memory.  The  problem  raked  by  case 
(1)  is  mainly  oa#  of  semantics.  The  problem  raked  by  ease  (2)  is  in  addition  eae  cf  uapkmeaUtioa 
efficiency. 

Araumlag  one  Ls  willing  to  accept  tc u:  v.  dictable  behavior,  there  b  ootalaj  rrr.-w«tiiag 
the  implemsaiatioa  of  shared  cbj-acts  La  a  skids  main  raemoxy  with  one  or  more  writers  being 
the  same  u  the  imp’^mcnurioa.s  of  the  rc.ad-oaiy  case  described  above.  Chang.-a  caa  be  nude  by 
any  process  that  has  a  rs/srsace  to  the  object  and  those  changes  will  he  rhible  to  etiwr  pro cc:.;.a 
with  a  reference  to  the  object.  For  some  United  set  of  applications,  this  uhssas  fair#  approach  is 
acceptable.  For  example,  suppose  the  shored  cat*  ccasrica  of  an  integer  that  needs  to  be  incremented 
when  a  particular  ev-aat  occurs  ia  any  one  cf  a  number  of  processes.  If  the  machine  has  na  atomic 
inerment-naeaaery  instruction,  then  this  implementation  will  work  fine. 

la  genera!  however,  if  there  are  to  be  writers  coexisting  with  other  writers  or  readers,  there  must  be 
synchronisation  ic  order  to  allow  the  predictable  and  correct  modification  of  data  structures.  For  an 
example  of  how  lack  cf  ryrschrcr.lsuioo  can  lead  to  problems,  consider  the  following  el&Kic  update 
problem:  suppose  one  procoa  is  travertin?  a  lint  of  objects  representing  a  list  of  employees  and 
modifying  the  salary  held  cf  each  employee  based  ca  seme  formula  (say  to  account  for  iadatioa); 
suppose  alto  that  at  the  some  time  another  process  Ls  modifying  a  single  employee’s  salary  to  account 
for  a  rabe  because  the  employee  boa  been  promoted.  The  two  proesjecs  might  elnnh  in  the  following 
way:  suppose  both  processes  (being  uncor.#  trained  by  any  synchronisation  nuchanism)  fetch  the 
salary  arid  for  the  employee  being  promoted.  The  hmt  process  computes  the  ce#  salary  and  stores 
b  back  into  the  person  objects;  the  second  process  nearly  simultaneously  computes  the  raise  and 
stores  that  new  salary  back.  Instead  of  the  employee  ending  up  with  an  increase  in  salary  due  to 
both  inflation  and  promotion,  he  gets  only  one  Increase  (ignoring  thb  sort  of  interaction,  there  is  the 
untie  of  which  increase  computation  thonld  be  done  first,  but  th'vt  is  not  a  synchronisation  concern). 

One  obvious  way  to  deal  with  thb  sort  of  concurrency  problem  is  to  make  all  request*  for  modifi¬ 
cations  go  through  a  single  process  (often  called  a  aumttor)  which  is  the  caiy  one  that  caa  actually 
modify  the  object.  Thb  sort  of  solution  has  two  problems.  First,  it  limits  concurrency  -  all  modifi¬ 
cation  requests  are  forced  to  line  up  and  be  executed  serially.  Thb  problem  can  be  ameliorated  by 
having  multiple  modifier  processes  each  of  which  b  responsible  for  a  disjoint  set  of  objects.  Unless 
you  have  one  process  per  object,1  concurrency  may  still  be  limited.  Another  problem  is  that  the  cost 
of  modifications  goes  up  tremendously;  it  b  bow  much  mere  expensive  to  modify  than  read  data. 
Some  database  systems  are  constructed  ia  thb  laritioc,  and  la  fact  both  writes  sad  reads  go  through 
an  intermediate  process.  Sine  we  are  designing  a  system  that  b  supposed  to  make  accessing  &ad 
modifying  permanent  objects  as  similar  as  p enable  to  accessing  and  modifying  transient  objects,  we 
consider  it  unacceptable  to  have  such  an  intermediate  process. 

.An  alternative  traditional  technique  for  dealing  with  concurrency  b  to  use  locks  (such  as  sema¬ 
phores).  (There  are  many  Language  constructs  in  existence  and  proposed  for  dealing  with  synchro¬ 
nization,  but  they  all  ultimately  rely  oa  locks.)  A  lock  controls  what  set  cf  processes  hav_-  what 
kind  of  concurrent  access  to  a  piece  of  data.  The  lock  can  be  specified  to  sl'ow  multiple  reader* 
and  no  writers,  or  one  reader/writer  sad  no  other  readers,  or  multiple  readers  and  writers  (the 
unconstrained  case  above).  Since  there  b  both  time  and  space  overhead  to  each  lock,  a  single  leek 
may  control  more  than  one  piece  of  data  in  erder  to  reduce  the  overhead.  The  locking  fr*u*/«ntp 
•ays  how  small  a  set  of  objects  need  to  be  locked  in  reality  in  order  to  loci  just  one  object.  A 
system  with  small  granularity  b  one  with  the  potential  for  high  concurrency  -  since  the  number  of 
object*  locked  with  one  lock  b  low,  the  chance*  that  other  processes  can  work  on  other,  unlocked 
data  b  high.  Conversely,  large  granularity  can  potentially  limit  concurrency.  Thus,  lock  granularity 
b  traded  off  against  potential  concurrency.  •  «• 

Now  let  us  consider  the  issue  of  concurrent  sharing  when  the  multiple  processes  do  not  share  a 


‘Hewitt  [25]  propoM*  such  a  system,  but  U  to  sot  clear  bow  practical  It  to. 
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common  main  memory.  Note  that  in  the  com  of  shared  main  memory,  the  thing  that  enabled 
sharing  to  be  implemented  easily  is  that  the  same  processor  using  a  single  memory  can  implement  a 
memory  reference  relatively  efficiently.  While  on  virtual  memory  systems  the  cost  of  implementing  a 
memory  reference  is  somewhat  higher  than  on  non- virtual  memory  systems,  the  cost  is  still  tolerably 
low.  Trying  to  extend  the  "virtuality"  of  memory  to  non-thaied  physical  memory  is  not  likely  to 
result  in  acceptable  performance.  That  is,  one  can  imagire  making  the  memory  reference  operation 
work  over  a  network  of  computers  each  with  its  own  private  memory.  However,  real  implementations 
of  systems  with  such  s  facility  have  never  been  entirely  successful.  At  best,  the  programmer  has 
been  forced  to  be  aware  that  some  memory  references  (i.e.  ones  to  local  memory)  are  cheap,  and 
others  (i.e.  ones  to  another  computer’s  memory)  are  considerably  more  expensive.3 

For  the  practical  purposes  of  building  an  implementation  on  conventional  machines,  we  chose  to 
disallow  concurrent  sharing  from  multiple  processes  using  disjoint  main  memories.  This  is  a  limi¬ 
tation,  but  not  one  that  is  impossible  to  live  with  because  one  can  often  divide  a  problem  so  that 
the  processes  that  need  to  access  data  concurrently  can  share  main  memory  with  each  other.  Also, 
even  when  processes  must  run  in  disjoint  memories,  it  is  often  possible  to  partition  a  data  structure 
so  that  parts  that  have  no  inter-dependencies  can  be  manipulated  in  separate  memories. 

2.1.5  Security 

For  many  applications  it  is  important  that  a  permanent  data  storage  system  provide  security  mech¬ 
anisms.  That  is,  it  should  provide  a  way  of  allowing  some  users  to  have  one  kind  of  access  and  other 
ucers  to  have  another  kind  of  access.  There  are  two  issues  to  be  addressed  in  this  area:  (1)  What 
is  the  granularity  of  the  specification  of  the  class  of  users?  (2)  What  is  the  granularity  of  the  data 
to  which  a  single  security  specification  applies? 

The  issue  of  the  granularity  of  the  specification  of  the  class  of  user  basically  comes  down  to  this: 
how  many  bits  of  specification  do  you  want  to  allocate  to  identifying  usetv?  Ideally  the  specification 
should  allow  different  access  to  be  specified  for  each  distinguishable  user.  If  there  are  a  lot  of  users, 
this  will  require  a  lot  of  bita.  If  this  specification  has  to  be  duplicated  for  each  object  to  be  protected, 
then  this  form  of  specification  is  unacceptable.  If  bowevsr  multiple  objects  that  are  to  be  protected 
identically  can  share  the  same  protection  specification,  we  are  less  likely  to  worry  about  the  length  of 
the  specification.  The  space  of  possible  protections  is  large,  bat  in  practice  the  number  of  different 
protections  used  is  relatively  small  compared  with  the  total  number  of  objects  being  protected.  The 
situation  is  further  helped  if  users  can  be  characterised  as  being  members  of  a  class  (ssy,  systems 
programmers)  rather  than  individuals.  Then  the  protection  applicable  to  an  entire  class  of  ucers 
can  be  expressed  amply  by  referring  to  the  class  instead  of  to  each  individual  user. 

Intertwined  with  the  issue  of  how  protection  is  specified  is  the  issue  of  bow  small  a  set  of  objects  can 
be  protected  by  a  single  specification.  Even  if  we  use  a  scheme  in  which  different  objects  can  share 
the  same  specification,  we  still  need  a  way  to  exprew  which  specification  we  want.  If  we  use,  ssy,  a 
32  bit  integer  to  identify  which  specification  we  want,  it  is  unlikely  that  we  would  want  to  protect 
sets  of  objects  m  small  as  or  approaching  32  bits  it  length  since  if  we  did,  the  storage  overhead  of 
the  specification  would  be  as  large  or  nearly  nr,  large  as  the  data  itself.  For  practical  purposes,  it  is 
usually  acceptable  to  allow  the  sise  of  the  set  of  data  to  be  protected  to  be  relatively  large. 


2.1.6  Reliability 

Reliability  is  a  measure  of  how  long  a  system  runs  without  failure.  Researchers  in  the  field  have 
made  many  suggestions  about  bow  programming  projects  can  produce  more  reliable  systems.  It  is 
not  dear  what  the  practical  implications  of  this  research  are  however.  For  our  purposes,  we  will 
have  to  rely  on  our  intuitions  about  reliability.  For  instance,  we  know  that  a  system  that  spreads 
one  set  of  logically  related  objects  over  multiple  disk  drivas  is  prone  to  reliability  problems  -  as 
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the  number  of  mutually  dependent  pieces  in  a  system  increases,  the  chances  that  the  failure  of  any 
individual  piece  affecting  the  reliability  of  the  system  increases. 

2.1.7  P-rf^nrsajnca 

I"  :J>;;".ni3e*  »  a  messcre  cf  how  Lut  a  system  runs  sr.d  how  much  space  it  csss.  If  pregr&cssei* 
r«  to  oi  p^siaaneat  objects  the  way  they  u*j  objects  in  a  traditional  programming  environment 
in  which  objxu  live  only  in  main  memory,  the  performsace  of  routines  thtit  amt*  and  access 
permanent  objects  must  be  similar  to  the  performance  of  analogous  routines  la  the  traditional 
environment.  It  is  easy  to  let  the  cost  of  the  operations  in  'the  perssaaeot  environment  creep  up.  By 
doing  so,  the  permanent  object  system  begins  to  look  like  a  traditional  file  system  as  programmers 
recognise  the  performance  problems  and  use  I/O  techniques  (like  buffering)  to  improve  performance. 


o  »> 
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Given  the  desire  to  maintain  objects  permanently,  cae  seeds  a  way  to  refer  to  those  objects.  Hie 
object  reference  can  be  thought  of  as  the  object’s  name.  There  are  a  number  of  questions  that  arise 
in  designing  a  reference  mechanism; 

•  What  is  the  form  of  the  reference? 

•  What  is  the  mechanism  and  coot  of  dereferencing  (i.c.  the  procedure  that  obtains  a  piece  cf 
an  object  given  the  object’s  reference j? 

•  How  many  layers  of  reference  does  the  system  provide? 

•  How  does  the  underlying  hardware  affect  the  choice  cf  reference? 

•  What  is  the  programmer ’*  and  the  user's  view  of  the  reference? 

The  first  thing  to  note  is  that  an  object  reference  is  ultimately  a  string  of  bits.  In  this  section  we 
will  disscua*  the  issues  associated  with  choosing  the  format  of  that  string  and  the  mechanisms  for 
dereferencing  given  the  bit  string. 


2.2.1  A  first  cat 

Permanent  objects’  permanent  home  is  on  stable  storage  -  a  dick  for  instance.  A  natural  first 
approach  to  the  problem  of  choosing  the  reference  form  is  to  say  that  an  object  reference  is  simply 
the  disk  address  at  which  the  object  begins.  Suppose  a  dkk  address  is  simply  an  integer  offset  that 
indicates  how  far  from  the  beginning  of  the  disk  the  object  being  referenced  is.  Dereferencing  then 
simply  consists  of  reading  the  appropriate  number  of  bytes  from  the  dkk  into  main  memory  where 
the  object  can  be  manipulated  by  the  CPU.  Let  us  refer  to  this  ss  the  pare  address  strategy. 

What  are  the  problems  with  the  pure  address  approach?  One  problem  is  that  since  it  is  reasonable 
to  arsume  that  objects  will  tend  to  be  larger  than  the  interval  between  disk  addresses,  if  our  object 
references  are  dkk  addresses,  then  we  are  wanting  bits.  This  is  because  even  when  the  disk  is  is 
full  of  objects  there  will  be  disk  sddreases  that  don’t  correspond  to  the  starting  position  of  some 
object.  Logically,  these  unused  addresses  represent  bit  patterns  that  could  in  principle  be  used  as 
object  references.  We  are  not  proposing  that  this  scheme  be  modified  to  use  those  addresses,  only 
that  their  existence  implies  that  we  are  not  getting  full  mileage  out  of  the  bits  we  have  allocated 
to  the  task  of  making  up  references.  Thus,  if  we  have  an  N  bit  references,  we  are  typically  going  to 
be  able  to  make  somewhat  less  that  2*  object  references.  Ideally,  we  would  like  to  be  able  to  get 
exactly  2‘v  references. 

Another  problem  with  the  pure  address  approach  is  that  it  makes  it  difficult  to  move  objects  around. 
Objects  might  move  around  for  several  reasons:  (1)  garbage  collection,  (2)  storage  compaction 
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(without  garbage  collection),  and  (S)  “logical  reasons*.  By  logical  reasons  we  mean  reasons  that 
are  not  real  requirements  of  the  system.  For  example,  suppose  the  system  consists  of  many  disks 
attached  to  many  computers.  Extend  the  notion  of  disk  ad  drees  so  that  the  disks  are  arranged  in 
some  order  and  each  disk  is  assigned  a  subrange  of  the  entire  disk  address  space.  An  example  of  a 
logical  change  is  a  inter’s  request  to  move  his  set  of  objects  to  a  disk  that  is  attached  to  his  computer 
instead  of  one  attached  to  another  computer,  ’f  we  use  the  disk  address  scheme,  then  moving  an 
object  requires  that  all  references  in  other  objects  to  the  object  being  moved  must  be  updated  to 
refer  to  the  new  address.  In  general,  this  is  equivalent  to  garbage  collection  -  the  entire  object  space 
may  have  to  be  swept  to  End  ah  the  references. 

A  refinement  on  the  pure  address  approach  that  solves  the  above  problems  is  to  have  a  table  that 
maps  references  onto  disk  addresses.  The  reference  assigned  to  an  object  is  a  key  into  the  mapping 
table.  Tbe  pr* '  lem  of  unused  bit  patterns  goes  away  because  the  reference  can  be  any  one  of  the 
bit  patterns  pwuble;  tbe  table  is  responsible  for  translating  all  valid  bit  patterns  (i.e.  patterns  that 
have  been  assigned  by  the  mapping  mechanism)  into  disk  addresses.  The  problem  of  moving  objects 
also  goes  away.  An  object’s  moving  is  transparent  to  the  holder  of  a  reference  because  the  only 
change  that  needs  to  be  made  is  to  tbe  mapping  table  slot  where  the  actual  disk  address  appears. 
Let  us  call  this  the  mapped  tidrttt  approach. 

Let’s  look  at  this  mapping  mechanism  in  more  detail.  The  obvious  implementation  is  to  have  a 
vector  whose  length  is  the  total  number  of  objects  (and  by  extension,  references)  we  wish  to  allow. 
Dereferencing  then  simply  consists  of  indexing  into  the  vector  at  the  position  indicated  by  the 
reference  and  returning  the  disk  address  found  at  that  slot.  This  vector  must  be  placed  at  some 
known  place  on  this  disk.  While  simple,  this  approach  obliges  us  to  maintain  a  potentially  large 
table  many  of  whose  slots  may  be  unused  if  all  the  possible  references  are  not  .being  use/!  at  any 
Jvtn  time.  Each  dereference  requires  that  we  read  the  disk  potentially  twice:  once  to  read  the  disk 
address  from  the  vector  and  once  to  read  the  data  located  at  that  disk  address. 

We  want  dereferencing  to  be  fast  -  dereferencing  is  in  tbe  inner  loof  of  all  processing  of  permanent 
data.  Slowing  down  dereferencing  slows  down  everything.  Tbe  mapping  mechanism  must  be  fast. 
As  an  optimisation  we  can  keep  a  copy  of  tbe  mapping  data  structure  in  main  memory.  This  saves 
us  one  of  tbe  disk  accesses.  Unfortunately,  having  tbe  table  in  main  memory  nukes  us  feel  even 
worse  about  tbe  table’s  sise. 

We  could  use  a  more  sophisticated  mapping  mechanism  like  hash  tables.  One  decides  how  big  to 
make  a  bash  table  baaed  on  tbe  expected  number  of  keys  (i.e.  references)  one  needs  to  map  into 
values  (i.e.  disk  addresses).  Thus,  we  can  reduce  tbe  sise  of  tbe  table.  However,  tbe  cost  of  ’ooking 
something  up  in  s  hash  table  is  considerably  greater  than  the  direct  lookup  that  is  done  in  s  vector. 

Any  kind  of  mapping  scheme  that  requires  large  parts  of  the  mapping  data  structure  to  reside  in 
main  memory  has  two  major  problems.  The  first  problem  is  odc  of  reliability.  We  are  ketping  a  data 
structure  that  is  critical  to  maintaining  the  consistency  of  the  complete  system  in  volatile  storage; 
if  the  system  crashes,  we’re  in  big  trouble.  To  reduce  the  potential  for  disaster,  we  can  periodically 
copy  the  mapping  data  structure  back  to  disk.  Nevertheless,  the  risk  remains. 

A  second  problem  with  keeping  tbe  mapping  data  structure  in  n;ain  memory  has  to  do  with  con¬ 
currency.  Multiple  processors  that  do  not  share  a  common  main  memory  do  not  have  equal  access 
to  the  mapping  data  structure.  It  is  likely  that  any  mechanism  that  tries  to  simulate  equal  access 
will  have  serious  performance  problems;  one  processor  will  run  quickly  while  the  others  run  slowly. 


2.2.2  Dividing  the  world 

The  cause  of  both  the  storage  overhead  and  concurrency  problems  noted  above  is  ultimately  that 
the  mapping  mechanism  is  flat  and  unpartitioned.  If  we  could  break  it  up  into  smaller  pieces  then 
(1)  tbe  amount  of  mapping  data  structure  that  needed  to  be  resident  at  any  time  would  be  reduced, 
and  (2)  multiple  processors  could  run  concurrently  as  long  as  they  stayed  in  separate  areas  of  the 
map. 
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Figure  2.1:  Multiple  table  mapped  addreas  dereferencing 


The  traditional  approach  for  breaking  up  a  mapping  mechanism  b  to  divide  the  reference  bit  string 
into  multiple  part*.  This  is  a  technique  that  i a  often  applied  in  virtual  memory  systems.  Each 
substring  of  biu  U  a  key  into  a  table.  All  but  the  last  substring  are  keys  into  tab-fa*  that  map  bit 
strings  into  table  identifier*.  The  last  table  maps  a  key  into  a  dUk  address.  The  first  table  is  at 
some  *well  known’  location.  Let  us  call  this  scheme  the  mol tipi*  teile  m«j*p s4  address  approach. 

Dereferencing  in  this  scheme  comists  of  breaking  up  the  reference  into  the  separate  bit  strings  and 
then  starting  with  the  well  known  table,  looking  up  each  substring  in  successive  tables  (the  location, 
of  each  table  is  the  result  of  the  previous  lookup)  until  the  last  substring  is  need.  The  last  substring, 
instead  of  being  an  index  into  a  table  of  table  identifiers,  is  an  index  into  a  table  of  disk  addreaaes. 
At  any  given  time,  only  one  of  the  table*  has  to  be  in  main  memory.  In  practice,  references  are 
broken  up  into  just  two  or  three  pieces. 

A  problem  with  the  multiple  table  approach  is  that  even  if  all  the  tables  happen  to  already  be  in 
main  r.jemory,  we  have  to  make  as  many  memory  reference*  as  there  are  table*  in  the  course  of 
just  oue  full  dereference  operation.  Lj  virtual  memory  systems,  this  problem  is  partly  helped  by 
introducing  special  hardware  that  store*  the  last  few  reference*  that  were  derefsrencad  along  with 
the  identifier  of  the  final  table  used  for  each  reference.  Any  future  reference  whose  upper  substrings 
match  an  entry  in  the  special  hardware  table  can  skip  the  process  of  looking  through  all  the  tables 
and  simply  u*e  the  result  saved  in  the  special  hardware  table.  This  process  is  sometime*  called 
tnntUtion  lookaside  (or  translation  caching). 

Let  us  now  consider  the  issue  of  storage  allocation  in  our  simple  disk  address  based  object  system. 
How  is  the  disk  space  managed  so  that  allocation  is  fast?  If  we  want  to  rely  on  garbage  collection 
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to  reclaim  free  (pace,  we  can  use  the  allocation  mechanism  described  earlier  -  amply  have  a  heap 
pointer  that  indicates  the  boundary  between  used  and  unused  dish  space.  Unfortunately,  now 
we  have  introduced  a  bottleneck  analogous  to  the  one  introduced  by  our  first  simple  mapping 
mechanism.  The  problem  now  is  allocation  instead  of  dereferencing  and  the  bottleneck  is  the  heap 
pointer  (or  in  general  whatever  data  structures  are  associated  with  the  allocation  process)  instead 
of  the  mapping  tabie.  All  requests  for  stoiage  have  to  go  through  the  allocation  data  structure. 

Just  as  we  broke  up  the  mapping  mechanism,  we  will  now  break  up  the  allocation  mechanism.  The 
straightforward  way  to  do  this  is  to  divide  the  entire  storage  pool  into  pieces  and  associate  separate 
allocation  data  structures  with  each  piece.  Let  us  call  a  piece  of  ’he  entire  storage  pool  a  hasp.  In 
fact,  it  will  tu:n  out  to  be  convenient  if  we  break  up  the  storage  pool  along  the  same  lines  as  the 
broken  up  mapping  mechanism.  Thai  is,  the  last  table  in  the  set  of  mapping  tables  will  contain 
disk  addresses  that  are  in  just  one  of  the  areas  of  the  disk  (Le.  storage  pool). 

An  advantage  of  the  heap  approach  is  that  now  instead  of  storing  full,  presumbiy  long,  disk  addresses 
in  the  table,  we  can  store  just  the  offsets  from  the  beginning  of  the  heap  on  the  disk;  one  entry 
in  the  table  contains  the  base  addrtss  (a  full  disk  address)  of  the  heap  covered  by  the  table.  In 
addition  to  being  small,  another  advantage  of  offsets  is  that  they  are  position  independent.  That  is, 
if  necessary,  we  can  move  a  heap  (say  to  another  disk)  without  having  to  change  anything  except  the 
base  address.  Another  advantage  that  we  will  go  into  detail  on  later  is  that  if  a  few  more  changes 
are  made  to  the  strategy,  it  will  be  possible  to  do  partial  garbage  collections,  i.e.  garbage  collection 
of  a  heap  rather  than  the  entire  storage  pool.  This  means  that  one  of  the  onerous  aspects  of  garbage 
collections  -  the  long  time  to  do  garbage  collection  -  can  be  somewhat  ameliorated. 


2.2.3  Dividing  the  world  is  not  free 

Note  that  as  a  result  of  the  divisions  in  the  reference  and  allocation  structures,  we  have  introduced 
the  problem  that  there  will  be  some  set  of  references  that  will  not  be  used.  How  does  this  happen? 
Without  loss  of  generality,  assume  that  the  reference  is  divided  into  just  two  pans.  The  first  pan 
is  conceptually  a  reference  to  a  heap;  the  second  pan  is  a  reference  to  a  particular  object  within 
the  heap.  The  maximum  number  of  objects  in  a  heap  is  fixed  by  the  size  of  the  second  pan  of  the 
reference.  We  expect  that  tne  assignment  of  objects  to  heaps  will  not  be  random  with  respect  to 
the  meaning  of  the  objects  -  that  for  rearers  that  will  be  elaborated  on  later,  programs  and  users 
will  place  logically  related  objects  in  the  same  heap. 

Assuming  this  model  of  the  use  of  heaps,  it  is  possible  that  some  heaps  will  contain  more  objects 
than  others.  As  a  result,  there  will  be  heaps  for  which  the  second  pan  of  the  reference  is  larger 
than  it  needs  to  be.  Unfortunately,  in  our  reference  scheme,  the  sizes  of  the  parts  of  the  reference 
are  fixed.  (Through  the  use  of  clever  encoding  techniques  it  is  possible  to  have  a  reference  scheme 
in  which  the  sixe  of  the  pieces  of  the  reference  can  vary  ‘by  need*;  we  consider  such  techniques  too 
expensive  for  our  purposes.)  Thus,  each  lightly  populated  heap  will  result  in  a  number  of  references 
that  are  not  used  (and  are  not  logically  usable).  Clearly,  we  need  to  pick  the  size  of  the  pieces  of  the 
reference  to  minimize  this  problem.  But  in  doing  the  division,  since  we  are  using  direct  lookup  and 
not  hashing,  we  are  obliged  to  pick  sizes  of  the  parts  of  the  reference  that  allows  for  the  maximum 
-  not  expected  -  number  of  objects  per  heap.  Since  we  can  assume  that  most  heaps  will  not  be 
completely  full,  we  will  have  unused  references.  This  is  the  price  we  pay  for  introducing  partitioning. 


2.2.4  Reusability  of  references 

While  we  didn’t  explicitly  state  it,  in  both  the  pure  address  and  the  mapped  address  approach,  we 
have  assumed  that  references  can  be  reused.  That  is,  if  an  object  is  deleted  (i.<.  discovered  to  be 
unreferenced  after  garbage  collection),  we  c.'m  reuse  the  reference  to  refer  to  some  newly  created 
object.  In  the  pure  address  strategy,  this  simply  means  that  we  can  put  some  new  object  in  a  place 
where  some  old  object  lived  and  that  the  disk  address  of  that  place  (the  reference  to  the  old  object) 
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dow  becomes  a  reference  to  the  sew  object.  Ia  the  mapped  uddrsss  *tmteQf,  it  meass  that  we  can 
Pease  the  slot  ia  the  mapping  data  structure  that  held  the  translation  between  the  reference  sad 
the  old  object’s  dhih  address  to  hold  the  ir&talatioa  betwsca  between  the  reference  and  some  new 
object’s  disk  address;  we  return  the  reference  to  the  old  object  to  the  allocator  of  the  sew  object. 

An  ilu-mate  approach  to  reusing  references  is  (obvicudy)  to  not  reuse  references.  Each  time  »  new 
obj.tct  Is  made  a  sew  rfeorrnc;  (cne  thet  hen  Laver  roferrod  to  tu;  object)  hi  nriJ-i  up.  The  approach 
»  cdfed  tie  sstfse  idcafe/fef  (or  simply  LTD)  approach. 

The  2r;t  question  that  arises  in  the  UID  appro-ch  is  *haw  do  you  guasrate  UIDrT®  Cue  trxdltioMl 
approach  is  to  use  a  clock;  a  clock  is  a  continuous  source  of  unique  nutuherx  The  seccnd  question 
is  "how  many  objects  will  ever  be  created T*  This  question  need?  to  be  answered  in  order  to  decide 
how  many  bits  long  the  reference  should  be.  Note  that  La  the  esue  c-f  ncn-UTD  systems,  the  rise 
of  the  reference  is  determined  by  how  many  objects  can  exists  at  any  itutaat,  not  how  many  will 
ever  exist.  In  either  case,  experience  veils  us  that  we  should  overestimate.  Chocking  too  small  a 
reference  is  something  to  avoid  because  running  out  cf  references  is  a  fixed  barrier:  when  it  happens, 
your  system  fails  apart.  Choosing  too  Lorre  a  reference  act  the  cost  that  you  can  waste  space  (and 
hardware)  allocating  bits  that  you  never  use.  There  is  no  simple  aiawor  to  tbs  problem.  One  thing 
is  for  sure  though  -  a  UID  system  seeds  more  bins  for  a  jvufereace  than  does  a  soa-UID  system. 

An  r-lvantage  to  the  UID  approach  is  that  objects  esa  be  explicitly  deleted  {he.  frsed)  without 
having  to  worry  about  dangling  references.  To  be  more  precise,  dusgiiag  refcKaces  an  still  a 
problem,  but  they  are  a  problem  that  will  be  detected.  As  toted  earlier,  in  a  con-UlD  rysizra, 
explicit  freeing  leaves  open  the  possibility  that  the  reference  will  be  reassigned  to  .%  naw  object  and 
that  dangling  references  (:.*.  references  to  the  old  object  that  are  cow  references  to  the  new  object) 
will  be  dereferenced  producing  meaningless  results.  In  a  UID  system  however,  when  the  object  is 
freed,  tie  reference  is  marked  as  being  invalid,  and  dereferencing  it  will  cause  an  error  that  can  be 
detected  by  the  etc  rage  system. 

The  disadvantage  of  a  UID  system  Is  that  the  cost  of  dereferencing  is  high.  The  data  structure 
that  maps  the  UID  into  a  disk  address  will  have  vo  be  complicated  (e.g.  a  hash  table).  There  is 
no  natural  way  to  divide  the  reference  as  wu  done  above.  (One  can  imagine  dividing  the  reference 
and  having  multiple  mapping  tables,  but  doing  so  would  not  produce  the  desired  benefits.) 


2.3  Types  and  Coda 

By  tad*  we  mesa  the  programming  language  procedures  that  implement  the  abstractions  discussed 
in  section  2.1.2.  It  must  be  possible  to  get  from  a  reference  to  an  object  to  the  code  that  implements 
abstractions  on  the  object.  We  call  the  characteristic  of  an  object  that  determines  what  code  should 
be  used  to  implement  abstractions  on  the  object,  the  object’*  {ype. 

In  a  traditional  programming  language  like  Pascal,  it  is  not  necessary  for  the  representation  of  an 
object  to  contain  un  indication  of  the  type  of  the  object.  This  is  because  all  variables  have  type*  and 
aa  object  ia  the  value  of  a  variable  or  the  value  of  some  field  of  an  aygregrite  whose  type  is  known. 
In  T  {like  all  Lisps),  variable*  do  not  have  types.  Thus,  the  type  of  an  object  must  be  explicitly 
associated  with  the  object  itself.  The  obvious  mecb&nkm  for  doing  this  is  to  allocate  some  apace  in 
the  object  to  hold  a  type  identifier.  Optimisation*  of  this  achem-.  will  be  discussed  in  section  3.2.1. 

Gives  that  type  ID*  are  kept  in  objects,  we  need  a  mechanism  that  takes  a  type  ID  and  returns 
a  procedure  that  takes  acme  operation  that  i*  to  be  performed  on  an  object  and  implements  the 
operation  cn  the  object.  This  procedure  is  the  handler  mentioned  in  section  3.1.  Ideally,  code  is  our 
world  of  permanent  objects  would  be  a  permanent  object  itself.  Thus  the  result  of  the  mechanism 
just  described  could  simply  be  a  reference  to  a  handler  object.  In  fact,  if  code  can  be  represented 
as  a  permanent  object,  the  ty  pe  ID  could  simply  be  a  reference  to  the  handler  object. 

One  reason  for  wanting  the  type  ID  to  be  something  other  than  a  reference  to  a  code  object  is  that 
we  can  assume  that  there  will  probably  be  more  objects  than  type*  of  objects.  A*  a  result,  the 
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number  of  bits  needed  to  hold  a  reference  is  larger  than  the  number  of  bits  needed  to  hold  a  type. 
Since  every  object  will  have  a  type  ID  embedded  in  it,  we  would  like  to  minimize  the  size  of  the 
type  ID.  Another  reason  for  having  a  layer  of  indirection  between  type  IDs  and  code  objects  is  that 
it  permits  a  level  of  abstraction.  Types  can  be  thought  of  independent  from  their  implementations. 
Implementations  can  be  changed  without  having  to  modify  all  the  objects  that  contain  the  type  3D. 

If  we  introduce  a  layer  of  indirection  between  type  IDs  and  eode,  we  must  keep  a  global  table  that 
maps  type  IDs  onto  code  objects.  In  order  to  avoid  making  this  table  a  bottleneck  in  the  system, 
each  process  would  presumably  keep  a  locrl  cache  of  the  map.  (Note:  this  solution  works  only  as 
long  as  the  handler  corresponding  to  a  given  type  ID  never  changes.) 

Another  issue  about  types  and  code  that  needs  to  be  addressed  is  haw  to  deal  with  type  redefinition. 
Suppose  we  create  a  'ype,  create  some  objects  of  that  type,  and  then  want  to  modify  the  behavior 
of  objects  of  that  type  (i.e.  how  those  objects  respond  to  operations).  Do  we  want  to  modify  the 
behavior  of  existing  objects  of  that  type,  or  only  objects  created  after  the  type  is  modified?  Also, 
what  if  the  type  definition  wants  a  different  number  of  slots  aligned  to  objects  of  that  type?  There 
are  cases  when  one  wants  old  objects  to  “see*  the  new  type  definition  -  for  instance  when  one  is 
fixing  a  bug  in  some  method.  There  are  cases  when  one  wants  them  not  to  see  the  new  definition,  in 
this  case,  one  might  be  inclined  to  call  the  change  an  introduction  of  a  new  type,  not  a  redefinition 
of  an  existing  type.  But  this  would  be  hiding  the  relationship  between  objects  of  the  old  type  and 
objects  of  the  new  type.  Suppose  a  bug  is  fixed  in  a  method  -  one  would  want  the  bug  fixed  in  both 
the  old  and  the  new  handler  (type  definition). 


2.4  Previous  Work 

Many  other  researchers  have  worked  on  systems  that  tried  to  solve  some  of  the  problems  discussed 
in  this  chapter.  We  will  briefly  discuss  some  of  that  work. 

2.4.1  Capability  systems 

Tue  tej.n  rspoii/itjr  system  [20|  is  usually  applied  to  a  system  that  is  specially  designed  to  keep 
track  of  references  to  objects.  Levy’s  masters  thesis  (So)  contains  an  excellent  summary  of  the  * 
systems.  In  capability  systems,  access  to  data  is  controlled  by  the  fact  that  a  process  can  refer  only 
to  objects  for  which  it  has  capabilities.  A  cejxbuxty  i*  essentislly  s  high-level  machine  address.  The 
only  way  to  obtain  a  field  of  an  object  is  with  a  machine  instruction  (or  kernel  call  on  machines 
that  do  not  have  capability-based  hardware)  that  takes  a  capability  and  an  offset  into  the  object. 
Unlike  other  systems  it  is  not  possible  for  unprivileged  processes  to  create  capabilities  from  other 
data  types.  Part  of  creating  «  process  is  the  assigning  an  initial  set  capabilities  to  tbe  process. 
The  process  can  then  pass  those  capabilities  onto  processes  that  it  invokes. 


2.4.2  Hydra 

The  Hydra  operating  system  for  the  C.mmp  multiprocessor  j54,16|  has  been  an  influential  model  for 
researchers  interested  in  capability  systems,  ""he  underlying  hsrdwure  (wh:ch  consists  of  PDP-lls) 
is  not  capability-oriented.  However,  Hydra  supports  capability-based  references  to  objects.  This 
functionality  is  supplied  by  machine  instructions  that  trap  to  the  kernel  which  then  authenticates 
the  reference  and  does  the  requested  operation. 


2.4.3  IBM  System  38  r 

While  they  have  long  bad  an  attraction  to  researchers  capability  systems  have  not  become  common 
in  the  real  world.  The  IBM  System  38  is  one  of  the  few  commercial  systems  based  on  the  capability 
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model.  The  System  58  hardware  La  capability-oriented.  In  spits  of  the  fact  that  is  has  an  object- 
oriented  model  -  the  system  presents  a  oae-Jt&eJ  object  store  which  eliminates  the  distinction  between 
objects  in  main  memory  and  objects  stored  on  the  dish  -  the  System  58  does  not  provide  anything 
other  than  a  traditional  programming  environment  (COBOL  and  RPG-I3). 
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2.4.4  Intai  1APX  432 

Intel’s  iAPX  432  microprocessor  and  associated  operating  system,  iMAX  422  [22,41]  is  a  recent 
commercial  entry  into  tire  world  of  capability  systems.  The  432  system  is  also  object-oriented,  but 
unlike  the  System  53,  the  432  makes  apparent  to  the  programmer  the  distinction  between  active 
and  passive  objects.  Passive  objects  aie  referred  to  using  80  bit  UIDs.  Active  objects  are  referred 
to  using  24  bit  432  access  descriptors. 

The  432  is  not  in  widespread  use  and  the  status  of  the  iMAX  project  is  undear. 

The  recent  trend  in  computer  architecture  design  has  been  toward  machines  with  a  considerably 
simpler  model  [43].  The  Unaware  that  supports  capability  systems  is  extensive.  As  a  result,  it  is 
hard  to  debug  and  hard  to  optimise. 

2.4.5  Smalltalk 

Smalltalk  [31,22]  is  a  language,  operating  system,  and  programming  environment.  The  only  suc¬ 
cessful  Smalltalk  implementations  have  been  on  microcodcd  personal  workstations.5 

Smalltalk  is  the  canonical  object-oriented  environment.  The  Smalltalk  language  introduced  many 
of  the  concepts  and  much  of  the  terminology  of  object-oriented  programming. 


2.4.0  SklsB 

The  Eden  project  [32,2,5,4]  is  a  project  attempting  to  build  a  distributed  computing  environment 
around  object-oriented  principles.  Eden  objects  are  relatively  expensive  and  heavy-weight  and  hence 
are  used  to  represent  a  collection  of  data.  In  Eden,  objects  are  active  entities.  When  an  operation 
is  applied  to  an  object,  a  process  corresponding  to  the  object  (not  to  the  invoker  of  the  object)  is 
activated  to  run  the  object’s  method  for  the  operation.  Part  of  the  Eden  project  is  the  development 
of  a  programming  language,  EPL,  baaed  on  Concurrent  Euclid.  The  purpose  of  £?L  is  to  allow 
Eden  objects  to  be  coded  conveniently.  Using  EPL,  active  Eden  objects  can  have  multiple  threads 
of  control.  _  — 

Originally,  the  Eden  project  expected  to  run  on  the  Intel  4S2  microprocessor.  However,  the  present 
Eden  prototype  is  running  on  multiple  VAXes  connected  via  a  local  Ethernet. 


2.4.7  Object-oriented  machines 

There  have  been  several  proposals  from  MIT  for  ‘object-oriented  machines*.  The  machines  bear  a 
resemblance  to  capability  machines  in  that  the  hardware  is  specifically  designed  for  keeping  track 
of  references.  None  of  the  proposed  machines  have  been  built. 

Bishop  [14]  describes  OPSLA,  a  system  with  a  very  large  lineal,  paged  address  space.  A11  processes 
run  within  the  tame  address  space.  Object  references  are  virtual  addresses,  not  UIDs.  The  address 
site  is  proposed  to  be  sc  mew  here  between  40  and  50  bits  (the  minimal  addressable  unit  is  a  64  bit 
word).  As  an  optimisation,  a  reference  contains  some  object  sise  and  type  information  hi  addition 


*TSe  recent  Implementation  of  Smalltalk  on  the  SMI  SUN  68000-baeed  workstation  (17]  apparently  approaches  the 
performance  of  the  better  microeoded  implementation;  it  is  not  dear  if  this  Implementation  will  succeed  in  making 
Smalltalk  more  widely  used  for  larje  applications. 
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to  the  virtual  address  of  the  object.  Thus,  the  *ue  of  an  ORSLA  reference  is  between  58  and  81 
bits. 

Bishop’s  main  idea  is  a  scheme  for  partitioning  the  address  space  into  sixes  and  allowing  areas  to  be 
garbage  collected  independently.  The  situ  scheme  depends  on  ir ter- area  references  going  through 
intcr-sm  links  so  that  the  garbage  collector  can  determine  the  root  set  for  the  collection  of  a  single 
area.  The  proposed  hardware  would  make  Inter-area  links  transparent  to  the  programmer. 

Lunicwski  [38]  describes  AESOP,  an  object  baaed  personal  computer.  AESOP  incorporates  some  of 
the  ideas  of  ORSLA.  In  addition,  Luniewski  investigated  some  of  the  programming  language  issues 
involved  with  working  on  the  proposed  architecture.  He  adopted  the  CLU  language  model  [36]. 

Snyder  [49j  describes  another  object-oriented  system  baaed  on  CLU.  His  thesis  discusses  come  of 
the  lower  level  hardware  issues  associated  with  such  a  system.  Also,  Snyder  proposed  the  use  of 
reference  counts  instead  of  garbage  collection  to  allow  storage  to  be  reclaimed. 


2.4.8  APL 

The  APL  workspace  [21]  is  one  of  the  earliest  examples  of  a  mechanism  that  supports  permanent 
structured  objects.  Early  APLs  provided  only  a  mechanism  for  copying  objects  from  one  user’s 
workspace  into  another.  Modem  APL  systems  provide  mechanisms  for  also  sharing  values  among 
workspaces. 


2.4.9  POMS 

The  Persistent  Object  Management  System  (POMS)  [7,8,9,10,42]  is  a  project  that  has  extended 
ALGOL  to  deal  with  permanent  objects.  The  underlying  permanent  storage  mechanism  is  the 
Chunk  Management  System  (CMS).  CMS  provides  a  database- like  interface  for  POMS.  On  first 
reference  to  a  permanent  object  POMS  requests  the  image  of  the  object  from  CMS;  POMS  deals 
with  a  copy  of  the  object  and  the  changes  made  by  the  program  using  POMS  is  not  made  permanent 
until  the  program  commits  the  changes  at  which  point  the  image  of  the  object  is  copied  back  into 
CMS. 


2.5  The  Smalltalk  -  Hydra  spectrum 

In  looking  at  the  various  systems  that  have  adopted  the  object-oriented  model,  one  can  ace  a  range 
of  concerns  to  be  addressed.  Smalltalk  and  Hydra  are  at  opposite  ends  of  several  spectra: 


Smalltalk 

Hydra 

object  site 

small 

large 

number  of  objects 

large 

very  large 

cost  of  dereference 

small 

large 

language  integration 

good 

bad 

objects  sharabie? 

no 

_ Z2 _ 

2.5.1  Object  fixe 

All  object-oriented  systems  are  designed  to  support  well  a  particular  range  of  object  sixes.  Ideally, 
a  system  should  support  a  range  of  sixes  from  just  a  few  bytes  to  thousands  and  millions  of  bytes. 
In  practice,  it  is  difficult  to  support  such  a  range.  One  finds  that  a  system  discourages  the  use  of 
small  objects  by  introducing  a  fairly  large  storage  overhead  per  object.  For  instance,  if  the  system 
imposes  a  16  byte  overhead  per  object,  it  is  unlikely  that  programmers  will  create  many  objects  of 
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16  byte*  or  less  -  programmers  will  tend  to  combine  several  logically  related  email  objects  into  cae 
larger  object  to  minimise  the  overhead.  This  obscuring  of  logical  objects  reduced  the  usefulness  of 
the  system.  In  fact,  if  the  per -object  penalty  is  krge  enough,  one  tends  to  view  objects  the  same 
way  one  views  Ska  in  a  traditional  operating  system. 

Smalltalk  is  oriented  toward  dealing  with  small  objects  -  every  piece  of  data  in  Smalltalk  is  an 
object;  the  Smalltalk  implementors’  experience  has  shown  that  average  object  sise  is  only  about  20 
byt*  (22).  The  per-object  overhead  is  8  bytes  (4  bytes  in  the  object  and  4  bytas  in  the  object  table). 
The  largest  object  is  12b K  bytes  (large,  but  probably  not  large  enough  for  all  applications). 

Hydra  is  oriented  toward  dealing  with  somewhat  larger  objects  than  Smalltalk.  The  per-objsct 
overhead  for  an  active  object  is  56  byUa;  the  per-object  overhead  for  a  passive  object  is  22  bytes. 
Aimes  [1]  points  out  that  these  overhead*  can  in  principle  be  reduced  to  32  and  16  bytes  respectively. 

2.5.2  Number  of  objects 

Another  design  aspect  of  object-oriented  systems  is  the  number  of  objects  that  can  exist  at  the  same 
time.  Traditional  Smalltalk  implementations  use  IS  bit  object  references  and  hence  can  support  S2K 
object*.  The  reason  this  number  isn’t  64K  is  became  Smalltalk  implementations  typically  encode 
integers  in  the  range  -2l&..  -f  215  —  1  in  the  object  reference  itself;  one  of  the  bit*  in  the  reference 
is  taken  to  mean  ‘I  am  a  small  integer,  not  a  real  reference*. 

Some  more  recent  Smalltalk  implementations  have  used  32  bit  references  (12),  but  it  is  not  dear 
that  they  are  designed  so  that  they  can  actually  support  2s3  objects.  LOOM  [28,51]  is  an  experi¬ 
mental  system  for  extending  the  Smalltalk  object  space  by  introducing  a  secondary  object  memory; 
the  Smalltalk  interpreter  automatically  moves  objects  between  primary  and  secondary  memory. 
References  to  objects  in  secondary  memory  are  32  bits  long. 

As  opposed  to  Smalltalk,  Hydra  was  designed  to  support  a  large  user  community  that  would  work 
on  Cjnmp.  As  s  result.  Hydra  was  designed  to  support  a  larger  number  of  objects  than  Smalltalk. 
Hydra  uses  a  64  bit  object  reference  which  is  composed  of  a  60  bit  field  which  contains  the  value  of 
a  1  microsecond  dock  at  the  time  of  the  object’s  creation,  and  a  4  bit  processor  ID.  The  increased 
per-object  storage  overhead  of  Hydra  as  compared  to  Smalltalk  is  in  part  due  to  the  larger  reference 
rise. 

2.5.3  Sharing  of  objects 

Another  area  in  which  Hydra  comes  out  ahead  of  Smalltalk  is  in  the  area  of  sharing.  Again,  since 
Hydra  was  designed  to  be  a  multi-user  environment,  it  needed  to  support  the  sharing  of  objects 
among  users.  In  Smalltalk,  each  user  works  in  his  own  object  space  and  there  is  no  (attractive) 
mechanism  for  sharing  Smalltalk  object*  among  different  Smalltalk  users. 

2.5.4  Coat  of  dereferencing 

In  Smalltalk,  all  objects  are  entered  in  an  object  UbU  ( OT ).  A  reference  to  a  Smalltalk  object  is 
an  index  into  the  OT.  The  OT  entry  for  an  object  contains  the  roemcry  address  of  the  object, 
a  reference  count,  and  other  miscellaneous  information.  Obtaining  a  field  of  an  object  requires  a 
memory  reference  to  the  OT  in  addition  to  the  memory  reference  to  obtain  the  field  itself.  The 
sise  of  the  OT  is  fixed  sad  the  entire  OT  must  be  in  main  memory.  For  Small  talks  with  16  bit 
references,  each  entry  in  the  OT  is  32  bits  long.  Thus  the  total  sise  of  the  OT  is  123K  bytes. 

In  Hydra,  an  object  can  be  either  passive  or  active.  An  object  is  activated  automatically  when 
a  field  of  the  object  is  request.  Hydra  uses  UIDs  as  object  references  and  hashing  as  part  of  the 
dereference  mechanism.  A  data  structure  called  the  sefit*  GST  keeps  track  of  all  active  objects 
(Le.  objects  In  main  memory).  A  data  structure  called  the  pesoive  GST  keeps  track  of  all  passive 
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objects  (i.e.  objects  oa  disk).  Obtaiainf  a  field  of  aa  object  requires  a  hashed  lookup  in  the  active 
GST;  if  the  object  is  fouad  there  then  the  main  memory  address  of  the  object  is  extracted  from 
the  active  GST  entry  and  used  to  pick  of  the  field  of  the  object.  If  the  object  is  not  in  the  active 
GST,  the  object  is  activated  (which  requires  reference  to  the  passive  GST)  and  then  the  procedure 
proceeds  as  it  does  for  aa  active  object.  This  process  of  obtaining  a  piece  of  a  Hydra  object  is 
handled  by  operating  system  code  and  is  initiated  by  a  user  process  by  executing  a  kernel  call  -  a 
special  machine  instruction  that  is  trapped  by  the  Hydra  operating  system. 

Hydra’s  reference  mechanism  is  dearly  more  expensive  than  Smalltalk’s.  The  aernel  call  in  Hydra 
can  be  used  to  copy  out  large  pieces  of  an  object  into  a  process’s  local  memory;  evident-ally  this 
feature  is  used  to  minimise  the  number  of  kernel  calls  necessary  to  obtain  an  object's  state.  The 
expense  of  dereferencing  encourages  programmers  to  make  largr  objects  whose  contents  can  be 
retrieved  with  one  kernel  call. 


2.5.5  Language  integration 

From  our  point  of  view,  the  most  serious  deficiency  of  Hydra  is  the  evident  lack  of  an  environment  for 
programmer’s  to  design  and  build  systems  based  on  object-oriented  principles.  From  the  descriptions 
of  Hydra,  it  is  not  at  all  dear  how  one  actually  programs  on  it.  Smalltalk,  on  the  other  hand,  is 
the  ultimate  in  object-oriented  programming  environments.  The  language  and  the  environment  are 
complete  integrated.  Tools  are  provided  for  inspecting  the  object  space. 


2.5.6  Summary 

The  point  of  our  Small  talk/Hydra  comparison  is  not  to  show  that  one  or  the  other  is  better. 
Rather,  the  point  is  to  show  how  two  systems  which  are  both  •object-oriented'  can  turn  out  so 
differently  as  a  result  of  different  goals.  Smalltalk’s  implementors  were  interested  in  making  a  single- 
user  programming  environment  to  exploit  the  concepts  of  object-oriented  programming.  Hydra’s 
implementors  were  interested  in  making  a  multi-user,  reliable,  multi-processor  operating  system 
based  on  object-oriented  principles. 

In  our  system  we  have  tried  to  find  a  mid-point  in  the  spectrum  of  possibilities  that  characterise  the 
differences  between  Hydra  and  Smalltalk.  It  would  be  fair  to  say  however,  that  we  started  at  the 
Smalltalk  end  of  the  spectrum  and  tried  to  generalize  to  a  system  that  has  some  of  the  properties  of 
Hydra.  The  Eden  project  is  an  example  of  a  project  that  started  at  the  Hydra  end  of  the  spectrum 
and  attempted  to  support  the  programming  ease  and  efficiency  of  Smalltalk. 


2.6  Message  passing  instead  of  object  moving 

An  essentially  different  line  of  research  that  is  concerned  with  sharing  of  data  concerns  the  support 
for  metstje  putting4  in  a  programming  system.  Thu  research  has  proposed  the  introduction  of 
programming  language  primitives  that  send  data  to  and  receive  data  from  other  proceases.  In 
the  systems  diaeuaeed  above,  data  is  manipulated  ..imply  by  dereferencing  a  pointer  to  tbe  data. 
Multiple  processes  can  access  tbe  data;  there  is  no  explicit  moving  of  data  among  tbe  processes 
wanting  to  access  tbe  data.  This  sort  of  secern  to  data  seems  natural  and  does  not  require  novel 
programming  language  constructs.  However,  access  to  tbe  data  is  unconstrained  -  synchronisation 
is  not  part  of  tbe  model.  Tbe  message  passing  approach  can  be  viewed  as  an.  attempt  to  allow  the 
synchronisation  of  processes’s  access  to  data. 


*N.B.  In  Smalltalk  and  other  languagee  with  similar  (oak,  ibis  tarts  is  often  used  to  mean  eotnethlng  like  “generic 
procedure  call’  bat  this  Is  set  Um  sene*  we  intend  here. 
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Extensions  to  CLU  have  been  proposed  to  allow  message  passing.  (23,24,50).  More  recently,  the 
Argua  project  [37]  has  Introduced  the  notion  of  ftsrdiia  u  the  repository  for  shared  data;  commu¬ 
nication  with  guardian*  is  implemented  via  the  lowir-lev.il  manage  pacing  mechanism. 


3.7  Summary  and  approach  of  tab  v/orl; 

The  framework  in  which  we  have  designed  and  built  our  system  for  maintaining  permanent  objects 
includes  the  following  assumptions: 

•  The  system  runs  on  conventional  hardware. 

•  The  system  runs  within  a  conventional  operating  system. 

•  Application  programs  that  use  the  system  are  written  in  an  extended  conventional  language. 

All  our  assumptions,  but  especially  these  throe,  result  from  our  desire  to  build  a  system  in  which 
we  could  experiment  with  prcyrammt'jsy  in  a  permanent  object  system.  Requiring  that  we  build 
hardware  or  operating  system  software  or  design  a  new  programming  language  would  have  mcresuwi 
the  scope  of  the  project  beyond  our  ability.  Given  the  alternative*  of  a  ieaa  than  ideal  system 
with  which  we  could  actually  experiment  oi  a  perfect  system  that  would  at  best  bo  only  p4rtially 
implemented,  we  chose  the  leas  than  ideal  system.  In  addition,  from  a  purely  experimenU-1  point 
of  view,  we  wished  to  demonstrate  that  the  implementation  of  th«*  concepts  does  not  absolutely 
require  sophisticated  new  Languages,  hardware,  or  operating  system  software. 

•  The  entire  space  of  objects  can  be  naturally  divided  into  sabspaces  (heaps)  of  objects. 

That  we  assume  that  the  space  of  objects  can  be  naturally  divided  means  that  there  will  be  some 
set  of  application*  for  which  our  system  will  not  be  useful.  For  instance,  if  the  object  space  consists 
of  a  ’arge  highly  connected  graph  of  object*  of  the  same  type,  there  may  be  no  natural  way  to  divide 
that  space.  Note  however,  that  if  the  undividable  space  is  imali  enough  jo  that  the  application’s 
objects  can  fit  within  the  largest  possible  heap,  the  application  can  uee  our  system. 

•  The  system  does  mat  provide  complete  transparency  for  the  application  programmer. 

A  system  that  provide*  complete  transparency  doe*  not  require  thit  the  programmer  know  the 
pattern  of  inter- heap  references,  or  what  kinds  of  objects  reside  in  whut  heap*,  or  in  what  heap  the 
next  object  should  be  allocated.  In  our  system,  the  programmer  does  have  to  know  these  things. 
We  hope  that  experience  with  using  a  system  like  ours  can  help  in  designing  a  practical  system  in 
which  complete  transparency  u  possible. 

•  The  system  doe*  *o(  provide  high  reliability  in  the  face  of  hardware  or  communication*  failure. 

This  assumption  is  related  in  part  to  the  first  two  assumption*.  Given  that  we  were  unwilling  to 
build  hardware  or  operating  system*,  it  i*  difficult  to  improve  the  reliability  of  our  system  beyond 
the  level  provided  by  conventional  hardware  and  software.  The  gross  reliability  of  our  system  is 
as  good  as  the  conventional  system  on  which  it  is  built.  Thi*  level  ir  good  enough  for  people  who 
uae  the  conventional  system,  so  it  ta  reasonable  to  believe  that  it  will  suffice  at  least  for  our  initial 
implementation.  In  the  long  term,  higher  reliability  is  probably  required  since  in  a  system  of  the 
sort  we  built,  the  loss  of  a  very  small  amount  of  data  can  potentially  lead  to  disasterou*  results. 

•  The  system  doe*  »«<  provide  mechanisms  for  a  high  degree  of  concurrency. 

We  are  interested  in  supporting  the  sharing  of  object*  by  multiple  processes.  Secondarily,  we  are 
interested  in  allowing  as  much  concurrency  a*  is  possible  using  conventional  technique*  (locking, 
busy  waiting).  W’e  believe  that  our  system  support*  the  solution  to  problem*  that  have  a  low  degree 
of  concurrency.  The  system  does  not  support  concurrency  among  processes  running  in  separate 
physical  memories. 
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•  The  system  supports  only  fairly  coarse  protection. 

If  a  system  is  to  provide  access  to  permanent  objects  that  is  nearly  a a  fast  as  i  ccess  to  transient 
objects,  it  seems  that  it  must  rely  on  special  hardware  to  allow  protection  dotra  to  the  level  of 
individual  objects. 


Chapter  3 

Implementation 

JL 


la  this  chapter  we  will  discuss  the  design  and  implementation  of  OM,  our  system  for  supporting 
permanent  objects.  We  will  be  concentrating  cn  the  lowest  levels  of  the  system. 


3.1  The  object  model 


The  model  of  data  that  we  will  use  in  this  thesis  is  typically  called  object-oriented.  This  model  has 
been  popularised  by  Smalltalk.  Since  the  term  has  different  meanings  to  different  people,  we  will 
briefly  describe  what  it  means  to  us. 

The  entities  in  object-oriented  system  are  (not  surprisingly)  objects.  An  object  b  a  piece  of  contigu¬ 
ous  storage.  Atomic  objects  have  pre-deuaed  storage  layout.  Non-atorak  objects  ai*  divided  into 
equal-died  slots;  each  slot  contains  a  reference  to  some  object.  Integers  and  strings  are  examples  of 
atomic  objects.  A  vector  is  an  example  of  a  non- atomic  object. 

An  important  concept  in  the  object-oriented  view  is  the  notion  of  reference.  Objects  do  not  contain 
objects,  they  contain  references  to  objects.  Thus,  two  different  objects  can  refer  to  the  same  object. 
Two  references  are  said  to  be  identical  if  they  refer  to  the  very  same  object.  Two  objects  are  said 
to  be  equivalent  if  there  is  no  way  to  tell  them  apart.  That  is,  any  procedure  applied  to  one  object 
yksda  the  same  result  as  the  same  procedure  applied  to  the  other  object.  Two  references  can  be 
norj-identical  yet  refer  to  equivalent  objects. 

Objects  can  be  mutable  or  not.  An  object  is  mutable  if  the  storage  occupied  by  the  object  can  be 
modified.  Integers  are  immutable  objects.  Strings  and  vectors  can  be  mutable.  A  mutation  to  as 
object  is  sometimes  called  a  tide-e fled 

Computation  occurs  by  invoking  operation*  on  objects.  (An  operation  is  the  same  as  %  Smalltalk 
message.)  When  an  opera.*! on  is  invoked  we  say  the  object  respond*  to  the  operation  by  executing 
some  code.  W'e  call  the  code  that  implements  the  response  a  method.  We  call  a  collection  of 
methods  a  handler.  The  type  of  an  object  is  defined  by  its  handier.  This  is  an  operational  view  of 
types.  Operations  are  generic;  Le.  they  can  be  applied  to  any  object.  However,  an  object  does  not 
necessary  handle  every  operation.  An  error  occurs  if  an  operation  is  applied  to  an  object  that  does 
not  handle  that  operation.  The  entire  process  from  operation  invocation  to  method  execution  is 
called  operation  dispatch. 

The  object  model  just  described  is  essentially  that  of  T.  Much  of  the  terminology  we  use  is  T’s. 
One  reason  for  using  this  model  is  that  it  is  T’s  model  and  our  system  will  be  running  within  T 
and  used  by  programmer’s  familiar  with  T’s  model.  Another  reason  we  use  this  model  is  that  it  is 
simple  -  objects  can  be  accessed  in  a  uniform  way. 
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3.2  The  Environment 

Tbe  environment  in  which  we  implemented  OM  consist*  of  the  T  programming  language  and  the 
Apollo  DOMAIN  computing  environment.  When  we  begin  the  project,  we  were  fully  aware  of  the 
fact  that  by  trying  to  work  within  an  existing  environment,  we  would  have  to  compromise  on  what 
functionality  we  would  be  able  to  support.  OM  does  not  provide  the  complete  transparency  and 
ease  of  use  that  many  unbuilt  systems  have  proposed. 

A  clear  advantage  of  working  with  existing  tools  is  that  we  were  able  to  more  quickly  address  the 
issues  _i  which  we  were  interested:  What  is  it  like  to  program  a  large  system  where  all  data  is 
stored  as  permanent  objects?  Can  such  a  system  be  made  efficient?  Another  advantage  in  not 
being  language  designers  is  that  our  end  product  is  not  a  system  that  is  unfamiliar  to  a  ready  user 
community  -  a  community  already  familiar  with  T  is  mote  likely  to  use  a  language  that  is  much 
like  T  than  they  are  a  totally  new  language.  Finally,  it  is  unproven  that  a  permanent  object  system 
actually  requires  a  special  purpose  language,  hardware,  or  operating  system.  We  wanted  to  see  how 
sophisticated  a  system  could  be  built  within  a  relatively  traditional  environment. 

3.2.1  The  T  programming  language 

T  is  a  dialect  of  Scheme,  which  in  turn  is  a  dialect  of  Lisp.  Scheme  differs  from  Lisp  mainly  in  the 
fact  that  variables  are  consistently  lexically  scoped.  In  this  respect.  Scheme  is  more  like  traditional 
Algol-like  languages  than  are  traditional  Lisp  implementations.  The  latter  rupport  dynamic  scoping; 
i.e.  the  value  of  a  variable  is  determined  by  the  contents  of  the  control  stack,  not  the  lexical  position 
of  the  variable. 

Scheme  supports  procedures  as  ‘first-class  objects’*.  That  k,  procedures  are  legitimate  objects 
(like  strings,  vectors,  and  pain1  that  can  be  bound  to  variables  and  p.isssd  m  arguments  to  other 
procedures.  Procedure  objects  are  created  by  the  LAMBDA  special  form3.  Procedure  objects  are  also 
known  as  closer**  because  when  a  LAMBDA  form  is  executed,  it  returns  a  procedure  object  that  is 
dosed  over  the  lexical  environment  of  the  LAMBDA  form.  That  is,  when  the  procedure  object  is  called 
and  the  body  of  the  procedure  is  executed,  references  to  variables  that  are  free  with  respect  to  the 
LAMBDA  form  but  that  are  in  the  lexical  scope  of  the  LAMBDA  form  yield  the  values  the  variables  had 
st  the  time  tit  procedure  ol/sct  was  crested. 

T  is  essentially  a  practical  realisation  of  Scheme.  Before  T,  there  were  no  practical  Scheme  imple¬ 
mentations  in  widespread  use. 

Like  many  Lisps,  T  runs  in  an  interactive  environment.  This  environment  contains  a  T  interpreter 
that  allows  the  debugging  and  incremental  redefinition  of  procedures.  The  T  compiler  takes  source 
files  and  produces  object  modules  that  can  be  loaded  into  the  T  interactive  environment  for  execu¬ 
tion. 

T,  like  ail  Lisp*,  is  a  language  of  reference.  That  is,  the  values  of  variables  are  references  to  objects, 
not  objects  per  se.  Different  variables  can  refer  to  the  same  object.  Objects  can  contain  references 
to  other  objects.  Procedures  return  references  to  objects.  In  general,  objects  are  allocated  in  heap 
storage.  T  uses  a  copying  garb  jge  collector  to  reclaim  storage  occupied  by  objects  that  are  no  longer 
reachable. 

T  references  are  32  bits  long.  The  low  3  bits  of  the  reference  are  used  as  a  type  esde.  The  type 
code  is  used  to  determine  the  type  of  the  object  being  referred  to.  For  instance,  if  the  type  code 
is  5,  then  the  object  at  the  ad  drew  specified  by  the  reference  is  an  adjacent  pair  of  references  -  an 
8  byte  T  pair.  The  high  29  bits  of  the  reference  is  a  virtual  address  in  quads  (8  byte  chunks),  not 
bytes.  Figure  3.1  shows  the  format  of  a  T  reference.  Note  that  a  quad  address  left  justified  in  a  32 

‘Liep’a  traditional  mm*  call  ia  called  a  “pair*  In  T. 

*Sfta*l  form  la  tha  traditional  Uap  tarn  for  ryntax  b>  the  taafuapa  that  la  need  to  denote  eonwthinf  other  then  a 
call  on  a  procedure. 
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Figure  3.1:  T  reference  format 


bit  word  la  a  byte  address  (i.e.  if  the  low  3  bits  of  a  reference  are  masked  to  zeros,  a  valid  machine 
address  results). 

Let  us  briefly  examine  how  this  sort  of  type  code  scheme  worhz.  In  T,  chooaiag  a  granularity*  of 
8,  the  low  three  bits  of  the  machine  address  of  an  object  are  always  zero.  Hence  in  a  T  reference 
these  three  bits  can  be  used  to  store  the  type  code;  this  requires  that  before  using  a  T  reference  as 
a  machine  address,  the  low  three  bits  must  be  cleared.  If  the  type  code  of  a  reference  is  known  (or 
can  be  assumed),  then  the  clearing  of  the  type  code  can  typically  be  done  ri  the  same  instruction 
that  fetches  a  field  of  the  object:  the  displacement  field  of  the  instruction  is  simply  decremented  to 
account  for  the  increment  that  the  type  code  will  cause.  In  T,  as  in  most  Lisp*,  the  machine  code 
produced  for  primitive  procedures  such  as  Chi  assumes  that  its  argument  is  a  pair  and  hence  it  can 
assume  the  type  code  is  a  particular  value. 

Given  fixed  word  and  type  code  field  sizes,  the  total  number  of  unique  reference*  i*  also  fixed.  As  the 
minimum  object  size  Is  decreased,  the  total  number  of  usable  references  decreases  (assuming  some 
objects  are  larger  than  the  minimum  object  size).  Thus,  in  effect,  as  the  granularity  decreases,  the 
total  number  of  objects  that  can  exist  at  a  time  decreases.  As  the  nainumum  object  size  is  increased, 
if  there  are  a  number  of  objects  that  are  logically  smaller  than  toe  minimum  object  size,  the  total 
amount  of  wasted  apace  increases. 

T  uses  a  granularity  of  8  because  Lisps  traditionally  make  heavy  use  of  objects  that  contain  exactly 
two  references. 

Since  T  needs  to  support  more  than  8  types  of  objects,  one  of  the  8  posable  type  codes  is  used  to 
rrseia  *th«  type  of  the  object  Is  encoded  in  the  first  ceil  (4  byte  quantity)  of  the  object*.  This  type 
code  is  called  the  extend  type  code.  The  first  cell  of  an  extend-type  object  is  called  the  object’s 
tempUte  pointer.  Objects  represented  in  this  way  are  called  extends. 

In  principle,  all  type  information  could  be  encoded  in  templates  and  no  type  code  in  the  reference 
would  be  needed.  However,  there  are  two  reasons  for  type  codes.  First,  they  allow  certain  objects  to 
be  represented  without  the  extra  storage  of  a  template  pointer,  e.g.  without  type  codes  in  references, 
eons  cells  would  have  to  be  8  cells  long  instead  of  2.  The  second  reason  for  putting  the  type  code  in 
the  reference  is  to  speed  up  the  process  of  determining  whether  a  reference  is  to  an  object  of  one  of 
the  frequently  used  types.  For  example,  given  a  reference  to  an  object,  one  can  determine  whether 
the  object  is  a  pair  simply  by  looking  at  the  reference  -  the  contents  of  the  object  itself  need  not  be 
examined. 

T  supports  the  stylo  of  object-oriented  programming  described  in  rxtion  3.1.  Recall  that  the  first 
step  in  operation  dispatch  is  to  get  from  a  reference  to  an  object  to  the  handler  associated  with  the 
object.  The  way  this  is  implemented  in  T  is  as  follows  (we  make  some  minor  simplifications):  if 
the  reference’s  type  code  is  not  extend,  then  the  handler  is  obtained  from  a  fixed  vector  of  handler 
procedures;  the  vector  is  indexed  by  type  code.  If  the  reference’s  type  code  is  extend,  then  object’s 
template  pointer  is  taken  to  be  the  reference  to  the  object’s  handler  procedure.  Once  the  handler 
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is  obtained,  T  calls  it,  passing  the  operation  being  invoked  as  an  argument;  the  handler  returns  the 
method  associated  with  the  operation.  T  then  calls  the  method. 

T  application  programmers  are  not  aware  of  the  machinery  of  operation  dispatch  described  above. 
The  OBJECT  special  form  allows  programmers  to  allocate  objects  and  specify  how  the  objects  are 
to  respond  to  operations.  Handlers  are  part  of  the  T  implementation  and  are  not  visible  to  pro¬ 
grammers.  Operation  invocations  are  syntactically  identical  to  procedure  calls.  In  T  source  code, 
procedure  calls  are  expressed  as  a  list  whose  head  is  an  expression  that  yields  a  procedure  object 
and  whoae  tail  is  a  list  of  arguments  to  the  procedure.  The  only  difference  between  this  and  the 
syntax  of  operation  invocation  is  that  the  head  must  yield  an  operation  object.  The  first  argument 
to  the  invocation  is  the  object  to  which  the  operation  is  applied.  Operations  are  defined  using 
DEFINE-OPERATION  which  has  a  syntax  similar  to  DEFIHE,  the  procedure  definition  special  form. 
The  body  (code)  of  the  DEFINE-QPEXATION  is  called  the  iefeuit  method  -  the  code  that  is  to  be 
executed  in  case  the  operation  is  applied  to  an  object  that  does  not  handle  the  operation.  If  the 
body  is  empty,  then  when  the  operation  is  applied  to  an  object  that  does  not  handle  the  operation, 
an  error  is  signalled. 

As  an  space  optimization,  certain  objects  are  not  represented  in  heap  storage.  These  objects  are  said 
to  be  represented  immediately.  Immediate  objects  are  represented  within  a  reference.  References 
with  certain  type  codes  are  taken  to  be  immediate  objects.  For  example,  if  a  reference  has  type  code 
0,  then  the  high  29  bits  of  the  reference  are  taken  to  be  an  integer  in  the  range  — 2a*..+22*  — 1;  T  calls 
such  integers  Fixnsm*.  Immediate  representations  are  important  because  one  wants  to  minimize 
the  allocation  of  heap  storage  that  will  become  garbage  quickly.  For  instance,  if  Flxnums  were  not 
represented  immediately,  then  the  ♦  procedure  would  have  to  allocate  space  in  the  heap  to  hold  its 
result.  If  this  result  was  not  saved,  but  only  passed  to  another  procedure,  as  in  (*  2  (+  3  4)), 
then  the  result  of  ♦  becomes  garbage,  resulting  in  the  heap’s  filling  up  quickly. 


3.2.2  The  Apollo  DOMAIN  computing  environment 

The  computing  environment  in  which  we  developed  OM  is  the  Apollo  DOMAIN  [5,6,33,34].  DO¬ 
MAIN  is  an  integrated  environment  of  high  performance  personal  nodes4  attached  by  a  high  speed 
(12M  bit/sec)  local  ring  network.  The  present  Apollo  hardware  uses  a  Motorola  MC68000  or 
MC68010  microprocessor  [40].  The  68000  instruction  set  is  traditional  and  memory  is  byte  ad¬ 
dressed.  A  node  typically  has  from  about  1M  to  2M  bytes  of  private  main  memory;  it  is  not 
possible  to  share  main  memory  among  multiple  nodes.  Each  user  node  has  a  high  resolution  bitmap 
display;  Apollo  makes  server  nodes  that  do  not  have  displays  but  which  can  be  accessed  from  other 
nodes  on  the  ring.  The  DOMAIN  software  supports  multiple  processes  on  a  single  node;  each  pro¬ 
cess  runs  in  its  own  virtual  address  space.  We  discuss  below  those  feature  of  the  DOMAIN  system 
that  are  relevant  to  our  work  (we  make  some  minor  simplifications  for  ease  of  presentation). 

The  DOMAIN  virtual  memory  architecture  presents  a  virtual  address  space  that  is  in  principle  234 
(16M)  bytes  long;  part  of  that  space  is  reserved  by  the  operating  system  and  the  amount  available 
to  user  code  is  about  6M  bytes  (it  is  expected  that  later  Apollo  hardware  will  support  a  larger 
virtual  address  space  as  true  32  bit  microprocessors  become  available). 

The  process  virtual  address  space  is  divided  into  IK  byte  pages.  For  a  page  to  be  usable  it  must  be 
mapped  to  a  disk  file.  By  page’s  being  “mapped'  we  mean  that  it  corresponds  to  a  page  in  a  disk 
file.  A  memory  reference  by  a  machine  instruction  to  a  virtual  address  in  the  mapped  page  yields 
a  piece  of  the  disk  file  page.  Depositing  a  value  into  a  virtual  address  modifies  the  contents  of  the 
file.  The  pager  is  responsible  for  optimizing  updates  of  main  and  disk  memories. 

Parts  of  the  address  space  are  made  usable  by  issuing  a  map  system  call.  The  call  takes  a  file  identifier 
(discussed  below),  an  offset  into  the  file,  a  length  to  be  mapped,  and  some  locking  information 
(discussed  below).  The  call  returns  the  virtual  address  at  which  the  file  is  mapped.  In  general,  the 
process  has  no  control  in  selecting  to  which  part  of  the  address  space  a  file  is  mapped.  Execution 
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of  machine  instructions  that  refer  to  parts  of  the  virtual  address  space  that  are  aot  mapped  result 
in  hardware  exceptions.  The  smallest  amount  of  virtual  address  space  that  can  be  mapped  is  32K 
bytes;  the  amount  mapped  is  always  rounded  up  to  the  nearest  32K  byte  quantity.  The  mmsp 
system  is  used  to  remove  association  between  the  address  space  and  some  file. 

Multiple  procaasas  ruar.inj  on  the  same  node  can  concurrently  map  the  s&zne  part  of  the  same  file, 
la  ^  mural,  the  files  may  be  mapped  to  different  places  in  each  process’s  virtual  address  space.  Both 
proceaoea  see  any  changes  made  by  the  other.  Multiple  processes  ruanias;  on  different  nodes  can 
map  the  tanc  file  for  read  access  only.  While  the  lowest  levels  of  Aegii  allow  multiple  processes 

on  different  nodes  to  map  the  same  file  for  write  access,  the  results  of  modifications  to  the  file  are 
undefined.  This  sort  of  access  to  files  is  not  officially  supported  by  Apollo. 

It  is  posable  to  map  a  segment  of  a  file  where  the  segment,  is  longer  than  the  current  length  of  the 
file.  As  references  are  made  to  parts  of  the  address  space  that  correspond  to  parts  of  the  file  that 
do  not  exist,  dkk  space  is  allocated  and  associated  with  the  appropriate  part  of  the  file.  Disk  space 
is  not  allocated  unless  and  until  the  reference  is  made. 

Thi  DOMAIN  operating  system.  Aegis,  does  not  present  any  traditional  I/O  system  calls  like  read 
or  trrfij.  The  only  I/O  is  done  by  the  .psger.  User  I/O  is  provided  via  a  user-state  subroutine 
library.  This  library  is  implemented  using  the  mapping  primitives. 

One  aspect  of  the  DOMAIN  system  that  makes  it  unique  among  commercial  workstations  is  that 
any  file  on  any  disk  attached  to  any  node  in  the  local  network  can  be  transparently  accessed  by 
any  process  on  any  node.  By  "transparent*  we  mean  that  the  accessing  process  doe*  not  need  to 
consider  whether  or  uot  the  file  is  on  the  disk  attached  to  the  node  on  which  the  process  is  running. 

Files  are  identified  by  a  84-bit  unique  identifier  (U1D).  File  UIDs  are  unique  across  all  Apollo  nodes. 
(The  DID  has  the  creating  node’*  hardware  node  number  embedded  in  lL)  The  kem*  node  of  a  file 
is  the  node  whose  disk  contains  the  file.  The  »tp  primitive  takes  the  UID  of  a  file  to  map.  The  file 
referred  to  by  the  UID  can  be  local  or  remote  (he.  on  the  same  node  as  the  process  executing  the 
map  call  or  not). 

The  call  to  mop  results  in  no  disk  I/O.  Pages  of  the  mapped  file  are  page  faulted  on  demand  from 
the  home  node  of  the  file.  The  first  reference  to  a  mapped  page  will  cause  a  page  fault.  At  that 
point  the  pager  either  reads  the  file  from  the  local  disk,  or  sends  a  ptfe-rn  request  to  the  home  node 
of  the  mapped  file.  In  the  latter  case,  the  pager  must  figure  out  what  the  file’s  home  node  is  baaed 
on  the  file’s  UID.  To  do  this,  presently  the  DOMAIN  system  allocate*  20  bit*  of  the  UID  to  be  the 
node  ID  of  the  home  node  of  the  file.  This  mean*  that  a  file  can  not  be  moved  between  nodes  (a 
file  can  be  copied  between  codes  and  the  original  copy  can  be  deleted,  but  the  copy  will  have  a  new 
UID  which  contain*  the  node  number  of  the  node  to  which  the  file  was  copied). 

Aegis  provides  a  set  of  system  calls  for  naming  files.  These  calls  allow  users  to  specify  text  path 
names  of  file*  (path  name*  are  like  Unix  file  names  [43j).  The  purpoae  of  the  naming  system  is  to 
translate  path  name*  into  UIDs.  The  naming  system  contains  directories  (which  are  represented 
as  filet)  that  translate  path  came*  into  UID*.  No  information  about  files  per  ne  (e.g.  file  length, 
location  of  file  on  disk)  is  stored  in  the  naming  system.  The  naming  system  could  logically  be 
implemented  outaide  of  Aegis  (modulo  a  few  details). 

Aegis  also  provides  a  simple  file  locking  mechanism.  For  our  purposes,  it  suffices  to  say  that  one  can 
control  how  many  processes  have  write  access  to  a  file  at  the  tame  time.  This  control  is  exercised 
at  the  time  a  file  is  mapped. 


3.3  Introduction  to  the  implementation  issues 

3.3.1  OM  within  T 


How  should  the  permanent  object  system  be  related  to  T7  We  see  two  different  approaches  to  this 
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question.  The  first  approach  is  to  think  of  T  as  the  implementation  vehicle  for  the  system.  In  this 
approach  the  programmer  is  lifted  up  from  T  and  works  consistently  is  a  oermaaent  object  world 
presented  by  the  system.  The  T  programming  Language  might  be  modified  in  some  ways  to  better 
handle  the  system’s  facilities  and  concepts. 

The  second  approach  to  setting  the  relationship  between  T  and  the  permanent  objact  system  Is  to 
think  of  the  system  as  a  set  of  utility  procedures  that  are  available  to  the  T  programmer.  The  user  of 
OM  still  programs  in  T;  he  calls  system  procedures  procedures  to  copy  T  objects  into  the  permanent 
object  space  and  back.  The  language  modifications  are  only  those  that  car.  be  Implemented  with 
T’s  syntax  modification  tools  (macros).  The  programmer  has  to  be  aware  of  when  he’s  dealing  with 
a  permanent  object  and  when  he  is  dealing  with  a  transient  object. 

The  second  approach  is  clearly  kas  desirable,  but  it  is  much  easier  to  implement.  Another  advantage 
of  the  second  approach  is  that  it  does  not  require  one  to  be  a  language  designer.  We  believe  that 
one  should  decide  what  a  language  that  is  designed  to  deal  with  permanent  objects  should  look  like 
only  after  one  sees  the  ways  in  which  standard  languages  are  inadequste  In  OM,  we  adopted  the 
second  approach.  The  result  was  acceptable,  but  less  than  ideal  in  ways  we  will  summarise  later. 

OM  is  written  entirely  in  T.  However,  OM  wss  written  with  a  detailed  understanding  of  how  T  is 
implemented.  W’e  present  the  OM  Implementation  with  respect  to  the  T  language  and  operating 
environment.  The  details  we  discum  are  in  general  not  apparent  to  the  programmer  who  wants  to 
tae  OM.  When  we  use  a  phrase  like  ‘To  T.  future  is  ...”  or  ‘In  the  OM  implementation,  future  is 
...”  we  are  describing  bow  some  aspect  of  OM  is  implemented,  not  how  it  appears  to  the  programmer 
who  uses  OM. 


3.3.2  Reference 

Our  first  concern  is  the  form  of  an  OM  reference  -  a  reference  to  a  permanent  object.  Just  as 
all  T  (i.e.  non-OM)  procedure*  take  T  references  to  T  objects  as  arguments,  OM  procedures  take 
OM  references  to  OM  objects  as  arguments.  Note  that  to  T,  OM  references  are  objects  of  some 
useivdefined  data  type.  But  to  the  programmer  using  OM,  OM  references  are  (sot  surprisingly) 
references  to  OM  objects. 

To  create  OM  references  within  T  we  could  use  the  standard  T  mechanism  for  introducing  new 
types  of  objects.  Unfortunately,  this  mechanism  is  expensive  -  all  objects  of  user-defined  types  are 
represented  in  the  heap.  It  is  unacceptable  for  OM  references  to  be  represented  La  the  heap.  If  they 
were,  all  procedures  that  return  OM  references  would  need  to  allocate  storage  simply  to  return  the 
OM  reference.  (We  are  not  talking  about  allocating  space  for  the  OM  object  itself.) 

Fortunately,  one  of  T’s  8  type  codes  is  unused  by  T.  With  virtually  no  modifications  to  the  imple¬ 
mentation  of  T,  we  can  use  this  type  code  for  OM  references.  Using  this  type  code,  OM  reference* 
can  be  represented  immediately.  Whatever  format  we  choose  for  the  reference,  it  most  fit  in  the 
upper  29  bits  of  a  T  reference. 

Are  29  bits  enough  for  an  OM  reference?  If  we  were  able  to  use  all  2**  references,  it  might  be. 
However,  we  intend  to  use  the  divided  mapped  address  reference  design  discussed  in  section  2.2.2. 
As  noted  in  section  2.2.8  this  means  that  we  expect  that  we  can  not  use  all  the  possible  references. 
Suppose  we  divide  the  reference  roughly  in  half  -  say  14  bit*  of  heap  identifier  and  IS  bits  of  within- 
heap  reference.  This  allows  16K  heap  identifiers  and  32K  references  per  heap,  assuming  we  maintain 
a  32 K  entry  table  that  translates  tbs  in-heap  reference  to  an  actual  byte  offset  within  the  heap. 

Let  us  consider  a  modification  to  the  multiple  table  mapped  addreee  scheme.  Instead  of  treating 
the  least  significant  part  of  the  reference  as  an  index  into  a  table  of  byte  offsets,  it  can  be  the  byte 
offset  itself.  The  advantage  of  this  scheme  is  that  we  save  one  table  lookup  (mtfnory  reference)  for 
each  dereference.  If  we  are  dividing  the  reference  into  just  two  pieces,  this  savings  is  significant  - 
we  have  just  one  table  lookup  instead  of  two.  The  disadvantage  is  that  we  partially  re-introduced 
the  problems  associated  with  the  pure  address  strategy:  the  inability  to  easily  move  object*  and  the 
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underuse  of  all  possible  reference  bit  strings.  However,  lacking  translation  lookaside  hardware,  we 
are  willing  to  p.„y  this  price.  A t  we  will  show,  these  problems  can  be  reduced  somewhat. 

If  we  use  this  modified  version  of  the  multiple  table  mapped  address  scheme,  14  bits  of  in-heap 
reference  does  not  look  so  attractive:  the  maximum  heap  site  would  be  just  16X  addressing  units 
;y  bytes)  -  dearly  not  large  enough,  if  we  expand  die  in-heap  reference,  we  must  reduce 
the  h.-’n.p  K’.iUtifier  pan  of  the  reference,  thus  reducing  the  total  number  of  heaps.  If  we  want  to 
Live  heap  idsnuilttrs  be  unique  for  ail  time  (to  allow  heaps  to  be  manually  deleted),  this  limitation 
Li  umtcoip  title. 

We  conclude  that  given  the  properties  we  want  of  our  object  system,  29  bits  is  not  enough  for 
an  object  reference.  Before  pursuing  s  remedy  to  this  problem,  let  u»  first  consider  some  of  the 
properties  of  data  structures. 


3.3.3  Tlia  structure  of  d^ta  structures 

Dam  structures  are  directed  graphs  of  objects.  La  practice,  the  graphs  representing  data  structure# 
are  not  arbitrary.  One  aee*  trees,  lists,  vectors,  DAGa,  etc.,  and  connections  between  graphs  of  these 
types  to  form  larg.-r  graphs.  As  a  result,  often  a  large  data  structure  has  natural  points  of  division. 
For  example,  if  a  data  structure  is  a  list  of  trees,  then  the  graph  is  naturally  partitionable  at  the 
connection  points  between  the  trees.  Note  that  this  is  a  thlit  property  of  a  data  structure. 

Graphs  of  <5ata  structures  may  also  be  partitioned  based  on  their  ifr.tra.ic  properties.  For  instance, 
some  vertices  may  be  examined  more  frequently  than  others.  There  may  be  locality  o  r,f trance 
among  the  vertices;  i.e.  a  graph  might  be  partitioned  into  subgraphs  whose  vertices  are  accessed 
around  the  same  time. 

In  building  a  permanent  object  storage  system,  one  can  ignore  the  partitionability  of  data  structures. 
Tbit  is,  if  the  system  provides  references  that  allow  an  object  to  refer  to  any  other  object  then  it 
can  certainly  implement  any  data  structure.  However,  such  a  system  is  overly  general.  In  general 
it  is  not  necessary  for  an  object  to  contain  a  reference  to  any  other  object  in  the  world;  it  need  only 
refer  to  acme  smaller  world  of  objects. 

Providing  the  general  functionality  is  expensive:  in  a  system  of  reference,  like  Lisp,  the  six*  of 
objects  other  than  atoms*  is  proportional  tc  the  site  of  the  reference.  Thua,  we  want  to  make  the 
site  of  a  reference  as  small  a a  possible  since  doing  so  will  reduce  the  amount  of  space  required  to 
represent  an  object.  Of  course,  if  we  make  the  sire  of  a  reference  too  small,  we  make  it  impossible 
to  refer  to  an  adequately  large  number  of  objects. 


3.3.4  Local  and  non-local  references 

How  do  we  take  advantage  of  the  locality  of  reference  among  objects  in  a  data  structure  while  still 
allowing  references  among  arbitrary  sets  of  objects?  Our  solution  is  to  allow  two  kinds  of  references: 
local  and  ncn-local.  Local  references  are  used  to  refer  to  ‘nearby’  and  logically  related  objects: 
objects  in  the  same  heap  as  the  source  of  the  reference.  Non-local  reference#  can  be  used  to  refer 
to  any  object.  Local  reference#  are  smaller  than  non-local  references.  There  are  two  dereference 
mechaniams,  one  for  local  references  and  one  for  non-local  references. 

There  is  a  problem  with  having  objects  connected  by  different  kinds  of  references:  when  a  program  is 
traversing  a  data  structure,  following  references,  it  need#  to  know  what  kinds  of  reference  the  object 
currently  being  examined  contains  so  that  (1)  it  can  extract  the  appropriate  number  of  bits  from  the 
object,  and  (2)  i‘.  can  apply  the  appropriate  dereference  mechanism.  Recall  that  our  original  mode! 
of  the  unolementation  of  a-i  object  (see  section  3.1)  is  that  an  object  is  a  vector  of  slots 

containing  reference*  to  other  objects.  In  a  straightforward  implementation,  if  there  are  different 
size  references,  the  slots  of  an  object  have  to  be  variable  rise  and  the  object  bra  to  have  a  descriptor 
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Figure  3.2:  Three  objects  La  two  heap* 


of  some  jort  that  allow*  procedures  that  want  to  extract  slots  from  object  to  tell  where  each  slot 
begin*  and  which  kind  of  reference  it  contains.  This  implementation  would  increase  the  cost  of 
accessing  slots  in  objects  by  an  unacceptable  amount. 

A  slightly  different  implementation  approach  that  supports  two  kinds  of  references  has  the  non-local 
references  stored  outside  the  object.  An  object  has  fixed  site  slots,  but  in  addition  to  being  able  to 
contain  a  reference  to  a  local  object,  a  slot  can  contain  a  reference  to  a  non-local  reference.  Any 
object  slot  that  needs  to  contain  a  non-local  reference  instead  contains  a  reference  to  a  non-local 
reference.  This  reference  to  a  non-local  reference  can  be  simply  a  local  reference.  Such  a  local 
reference  can  be  distinguished  from  a  local  reference  to  a  local  object  by  reserving  a  bit  for  just 
that  purpose.  This  bit  ran  be  either  in  the  local  reference  or  in  the  storage  pointed  to  by  the  local 
reference.  We  will  discuss  this  in  detail  later. 

In  summary,  all  objects  that  reside  in  the  same  heap  can  rv/er  among  themselves  using  local  refer¬ 
ences.  The  slots  in  an  object  are  the  site  of  a  local  referroce.  For  an  object  in  one  heap  to  refer  to 
an  object  in  another  heap,  it  must  go  through  an  intermediate  non-local  reference.  We  assume  that 
inter- heap  references  are  infrequent.  Another  way  of  saying  this  is  that  objects  that  are  part  of  one 
data  structure  or  partition  of  a  data  structure  are  in  a  single  heap. 

Figure  3.2  diagrams  three  objects  in  two  heap*.  Object  A  (which  has  5  slots)  contains  a  reference 
to  object  B  (which  has  2  slot*).  Both  objects  A  and  B  are  in  heap  1.  Object  A  also  contains  a 
reference  to  object  C  (which  has  3  slots).  Note  that  object  C  is  in  heap  2.  Thus,  for  object  A  to 
refer  to  object  C,  there  must  be  a  non-local-reference  (labelled  X  in  tee  diagram). 

The  nice  property  of  this  approach  is  that  it  is  cheap  in  terms  of  both  time  (i.e.  time  to  follow 
a  reference)  and  space  (i.e.  space  occupied  by  a  reference)  to  connect  two  objects  that  are  in  the 
same  heap.  Thus,  we  ars  optimising  the  kind  of  activity  we  expoct  to  occur  most  frequently:  local 
traversal  and  local  reference.  By  local  traversal  we  mean  the  following  of  references  between  objects 
within  the  same  partition;  programs  tend  to  localise  their  traversal  to  a  partition  of  a  data  structure 
(this  is  similar  to  the  locality  of  reference  argument  in  virtual  memory  systems).  By  local  reference 
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Figure  3.3:  RPointer  representation 


we  mean  reference  between  two  objects  within  the  time  partition;  an  object  within  a  partition  moat 
frequently  needs  to  contain  a  reference  to  another  object  within  the  same  partition. 

An  important  property  of  local  references  is  that  they  are  meaningful  only  in  the  context  of  acme 
heap.  That  is,  in  order  to  knew  what  a  local  reference  refers  to,  one  has  to  know  with  what  heap 
the  local  reference  is  associated.  The  simple  and  obvious  rule  here  is  that  a  local  reference  is  always 
associated  with  the  heap  from  which  the  local  reference  was  itself  extracted.  Local  references  are 
r.ot  created  out  of  thin  air.  All  local  references  come  t-m  inside  of  objects  that  reside  ia  some 
heap  or  are  returned  by  a  primitive  that  creates  new  objects.  In  the  latter  case,  the  heap  is  known 
because  it  was  suppl>d  by  the  caller  to  the  creation  primitive.  In  the  former  case  whoe  ’er  did  the 
extraction  must  have  known  what  heap  he  was  extracting  from  and  can  associate  the  extracted  local 
reference  with  that  same  heap.  The  only  question  is  how  one  gets  the  first  reference  from  the  first 
heap.  We  will  address  this  question  later. 

We  use  the  term  RPointer  to  mean  ‘local  reference*.  RPointer#  are  byte  offsets  fi^m  the  base  of 
the  heap  in  which  the  object  being  referred  to  resides.  (The  ‘R*  in  “RPointer*  comes  from  the  fact 
that  RPointer#  are  Relative  to  the  base  of  a  heap.)  We  use  Fs  spare  type  code  to  indicate  an  object 
of  the  T  type  OM  RPointer.  RPointer#  are  represented  immediately  in  the  29  upper  bits  of  the  T 
reference. 

We  can  now  re- ad  dress  the  issue  of  the  site  of  reference.  A  29  bit  RPointer  allow#  heaps  up  to  more 
than  5G0M  bytes;  objects  can  be  up  to  this  length.  This  certainly  seems  like  enough  for  the  near 
future. 


3.3.5  TtPointers  within  T 

It  is  important  to  understand  that  to  T  there  is  nothing  special  about  RPointer#  -  they  are  simply 
29  bit  objects.  OM  mimics  Fs  implementation  of  type*  the  low  3  bits  of  the  RPointer  form  a  type 
code  which  indicates  the  type  of  the  OM  object  referred  to  by  the  RPointer.  The  meaning#  of  the 
OM  type  codes  (i.e.  what  type  code  means  wbat  type)  is  different  from  the  meaning#  of  the  T  type 
cedes. 

Figure  3.3  shows  the  format  of  an  RPointer  within  a  T  reference. 


3.3.6  Object  code 

In  the  present  implementation  of  OM,  object  code  can  not  reside  in  OM  heaps.  All  code  is  loaded 
into  the  transient  heap.  The  reason  for  this  limitation  is  that  the  nature  of  an  object  module 
produced  by  the  T  compiler  requires  that  when  it  is  loaded  into  a  process,  portions  of  the  module 
must  have  process  virtual  address  written  into  the  representation  of  the  module  in  memory.  We  can 
not  allow  such  process-dependent  information  in  OM  heaps. 
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Tb«  structure  of  object  code  is  complex  ud  intertwined  with  the  T  Compiler.  When  compiling  a 
module  the  T  compiler  produces  sn  object  module  that  contains  4  pure,  position-independent  code 
section  and  an  impure  data  section.  The  pure  code  refers  through  the  data  section  to  get  at  values 
of  variables  In  other  modules.  (Since  T  doesn’t  have  special  “function  cells*  but  rather  uses  the 
normal  variable  binding  mechanism  to  store  procedure  values,  the  looking  up  of  values  of  variables 
in  other  modules  is  common.)  When  a  module  gets  loaded,  the  part  of  the  data  section  that  is 
used  this  way  by  the  code  gets  filied  in  to  contain  references  to  all  the  non-local  variables  that  are 
referred  to  by  the  code  in  the  module.  Hence,  the  data  section  becomes  impure. 


3.4  Heaps 

3.4.1  Heaps  in  plain  T 

T  allocates  objects  using  a  simple  heap  allocation  system.  At  startup  it  allocates  two  large  pieces 
of  the  process  virtual  address  space.  We  call  these  pieces  the  transients  heaps.  Since  Aegis  does  not 
support  the  traditional  concept  of  swap  space  (i.e.  pieces  of  the  disk  that  are  dedicated  to  backing 
process  pages  that  are  not  part,  of  a  disk  file)  T  obtains  these  pieces  of  address  space  by  mapping 
two  temporary  files  into  the  process  virtual  address  space.  These  files  are  deleted  when  T  exits. 

Only  one  transient  heap  is  active  at  a  time.  A  heap  pointer  held  in  a  hardware  register  is  initialized 
to  hold  the  virtual  address  of  the  beginning  of  the  active  transient  heap.  When  a  procedure  wants 
some  storage  to  hold  an  object,  it  simply  increases  the  heap  pointer  by  the  amount  of  storage  it 
wants  (rounded  up  to  the  nearest  multiple  of  8  bytes)  and  uses  the  old  value  of  the  heap  pointer 
as  the  reference  to  the  new  object.  When  the  heap  pointer  reaches  the  end  of  the  active  transient 
heap  (i.e.  when  there  is  not  enough  room  in  the  active  transient  heap  to  allocate  an  object)  a  GC 
flip  occurs:  the  inactive  heap  becomes  the  active  heap  and  a  copying  garbage  collector  is  invoked  to 
copy  all  the  reachable  objects  from  the  previous  active  heap  into  the  current  active  heap.  The  set 
of  reacfubie  objects  is  determined  by  recursively  following  all  references  from  the  root  tel  of  objects 
kno \*x.  *■  priori  by  the  garbsgt  collector  and  all  references  from  variables  on  the  program  execution 
atr  -Jv. 


3.4  2  01 Vi  Heaps 

Since  OM  ran.  'thin  an  existing  operating  system  that  has  its  own  ideas  about  using  the  disk,  we 
have  tii  work  w-vhin  the  operating  system’s  filesystem.  This  is  not  too  much  of  a  problem  -  we  can 
simply  eml—  our  system  within  a  single  large  file.  However,  if  we  expect  to  work  in  a  multi-user, 
multi-ippll  .n  environment  it  probably  makes  more  sense  if  we  use  one  file  per  heap.  This  allows 
individual  1 1 .  1  or  applications  to  use  normal  file  system  primitives  to  copy,  delete,  backup,  protect, 
and  if  tvxxss&ry  examine  the  contents  of  heaps  be  controls.  If  all  the  objects  resided  in  one  large 
file  our  system  would  have  to  duplicate  these  tools.  We  can  consider  each  heap  file  as  a  separate 
disk  and  the  system  can  function  along  the  lines  discussed  earlier  about  a  multi-disk  system. 

OM’s  basic  extension  to  T  is  the  introduction  of  support  for  multiple  simultaneously  active  b-aaps. 
OM  provides  primitives  for  creating  objects  in  these  heaps.  These  primitives  take  an  argument  that 
identifies  the  heap  in  which  the  object  is  to  be  created.  OM  also  provides  primitives  for  accessing 
slots  within  objects.  These  primitives  take  both  an  argument  that  identifies  the  heap  in  which  the 
object  resides  and  an  RPointer  argument  which  identifies  the  particular  object  within  the  heap. 

An  OM  heap  is  mapped  into  the  process  virtual  address  space  when  objects  in  the  heap  need  to 
be  referenced.  The  process  of  mapping  is  not  very  cheap;  it  requires  no  disk  I/O  until  a  reference 
u  made,  but  the  map  call  is  a  system  call  (requiring  a  context  twitch)  and  the  manipulation  of 
the  memory  translation  hardware  by  Aegis  is  expensive  compared  with  the  cost  of  doing  a  single 
memory  reference.  However,  we  assume  that  once  a  heap  is  mapped  that  many  references  to  objects 
within  the  heap  will  be  Aade.  We  believe  that  the  way  to  measure  the  performance  of  a  system 
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such  as  ours  is  to  measure  the  average  cost  of  a  reference.  If  the  number  of  references  per  mapping 
operation  ia  high,  than  the  average  cost  of  a  reference  b  not  substantially  affected  by  the  cost  of 
the  mapping  operation. 

OM  heaps  are  position  independent.  An  OM  heap  b  a  collection  of  OM  objects  that  refer  to  each 
other  vein g  RPolaters.  Recall  that  RPointsra  are  offsets  from  the  base  of  the  heap.  This  allows  heaps 
to  be  placed  at  any  position  in  the  virtual  address  space  without  having  to  relocate  the  contents  of 
the  heap. 

There  are  two  reasons  for  wanting  to  avoid  relocation  to  account  for  the  position  that  a  heap  b 
mapped  at.  First,  the  cost  of  activating  a  heap  (i.e.  the  steps  required  before  the  objects  of  interest 
in  a  heap  can  he  examined)  would  be  intolerably  high.  Worae  yet,  the  cost  would  be  proportional  to 
the  number  of  objects  in  the  heap,  not  the  number  of  objects  one  needs  to  examine  (“on  demand'* 
relocation  oeems  overly  complex).  The  second  problem  b  that  if  the  heap’s  contents  are  relocated, 
then  the  heap  can  not  be  used  simultaneously  by  multiple  processes  running  on  the  same  node.  This 
is  because  the  processes  can  not  guarantee  that  the  heap  would  be  mapped  into  the  aame  part  of 
the  virtual  address  space  for  ad  processes  wanting  to  access  the  heap. 

3.4.3  Naming  OM  heaps 

The  primitives  that  activate  and  deactivate  heaps  must  have  a  way  of  referring  to  heaps.  As  we 
•aid  earlier,  heap*  are  stored  in  DOMAIN  file*,  one  heap  per  file.  There  are  three  possible  ways  of 
naming  heaps: 

1.  Use  DOMAIN  path  names  (variable  length  strings). 

2.  Use  DOM./  IN  file  UID*  (64  bit  integers). 

3.  Make  up  our  own  naming  scheme. 

Approach  (1)  is  the  obvious  approach  -  user*  are  already  accustomed  to  dealing  with  DOMAIN 
path  names.  The  DOMAIN  naming  system  allows  files  to  be  organised  hierarchically;  related  heaps 
could  have  similar  name*.  The  drawback  to  using  path  names  b  that  they  are  long  and  not  of 
fixed  length;  this  increases  the  overhead  required  for  manipulating  them.  As  we  will  see  later,  heap 
names  need  to  be  embedded  inside  OM  data  structures  and  will  be  manipulated  fairly  frequently. 
Also,  using  path  names  means  that  the  heap  activation  time  includes  the  time  it  takes  to  turn  a 
path  name  into  a  file  UID. 

Approach  (2)  solves  the  overhead  problems  and  saves  the  pathname  to  UID  conversion.  However, 
UIDs  are  elements  of  a  flat  name  space.  The  DOMAIN  user  interface  b  designed  to  deal  with  path 
names,  not  UIDs.  For  a  prototype  system  such  as  the  one  we  built,  we  want  to  make  it  convenient 
to  deal  with  failures  using  tools  in  the  surrounding  environment.  Using  UIDs  would  have  made  this 
difficult. 

We  adopted  approach  (3).  Our  naming  scheme  uses  29  bit  heap  unique  identifiers  called  HIDt. 
Being  fixed  length  and  small,  HID*  are  easy  to  manipulate.  EIDs  are  assigned  by  OM  which  keeps 
a  global  word  that  holds  the  number  of  the  next  HID  to  assign.  We  assume  that  heaps  are  created 
relatively  infrequently  so  that  having  a  single  global  word  won’t  be  a  serious  bottleneck. 

OM  maintains  a  permanent  global  table  translating  HIDs  into  DOMAIN  path  names.  When  a 
HID  b  presented  to  the  heap  activation  primitive,  the  HID  b  translated  into  a  DOMAIN  path 
name  which  b  in  turn  translated  into  a  UID  of  a  file  which  b  then  mapped.  (The  translation  table 
also  can  translate  file  names  into  HIDs;  thb  feature  b  useful  for  debugging.)  There  b  no  reason 
that  the  HID  translation  table  couldn’t  convert  HIDs  into  UIDs  except  for  tbe  prototyping  problems 
mentioned  above.  If  OM  were  to  be  made  into  a  production  system,  we  vo*ld  have  the  table  contain 
a  HID  to  UID  translation.  •  r 

The  global  table  b  itself  represented  as  a  OM  object  -  a  permanent  hash  table.  The  HID  and  path 
name  of  the  heap  holding  the  table  object  are  known  a  priori.  Thb  heap  U  called  the  HID  keep. 
The  HID  Leap  b  also  the  place  where  the  “next  HID  to  use*  counter  b  kept. 
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The  HID- to-patb- name  translation  table  is  a  potential  bottleneck.  One  way  in  which  we  reduce  this 
problem  is  by  having  processes  that  are  using  OM  keep  n  cache  of  translations  that  have  already 
been  requested.  (The  cache  can  implemented  as  a  hash  table  kept  in  each  procos’s  address  space.) 
Once  a  HTD  has  been  translated  in  one  process,  future  translations  of  the  same  BID  do  not  need 
to  consult  the  global  table.  This  is  possible  since  HID*  are  unique  and  never  reassigned  to  refer  to 
some  other  heap. 

Another  way  to  avoid  the  bottleneck  of  a  global  HID  translation  table  is  to  have  multiple  tables. 
This  be  implemented  by  dividing  the  HID  into  pieces  in  a  way  analogous  to  the  scheme  for 
dividing  object  references.  In  our  prototype  system  the  OM  user  can  specify  the  path  name  of  the 
HID  heap  so  he  can  run  his  own  private  world  of  heap*  and  permanent  objects;  he  can  tb”s  reduce 
the  number  of  processes  contending  for  access  to  the  HID  heap.  In  the  prototype  system  each 
isolated  application  area  -  he.  a  set  of  application  programs  that  do  not  need  to  refer  to  objects  in 
another  set  01  application  programs  -  has  its  own  HID  heap.  This  is  not  a  restriction  of  the  current 
system;  rather  it  is  a  suggested  mode  of  operation  that  seems  prudent  while  aspects  of  the  system 
are  still  under  development. 

3.4.4  Active  heaps 

When  a  heap  is  activated,  the  heap  can  be  characterised  as  a  virtual  address  in  a  process  and  a 
length  (he.  the  amount  of  space  the  heap  occupies  in  the  address  space).  We  refer  to  the  starting 
virtual  address  of  an  active  heap  as  an  RHtopB.  The  RHeapB  of  an  active  heap  is  all  that  is  needed 
to  dereference  RPointen  into  the  heap:  the  RHeapB  b  added  to  the  RPointer  to  form  a  virtual 
address  of  a  particular  object. 

It  turns  out  that  it  is  necessary  to  associate  some  additional  information  with  an  active  heap.  An 
object  of  a  type  called  RHttp  holds  all  the  information  associated  with  an  active  heap.  RHeap 
objects  contain: 


•  The  RHeapB  of  the  heap. 

•  The  number  of  bytes  mapped. 

•  The  HID  of  the  heap. 

•  The  activation  count  of  the  heap  for  this  process. 

The  heap  activation  primitive  returns  an  RHeap  record.  All  the  OM  primitive  procedures  for 
manipulating  OM  objects  take  an  RHeap  argument. 

The  purpoee  of  the  RHeapB  field  is  clear.  The  reason  for  the  byte  count  field  is  that  the  DOMAIN 
unmap  primitive  requires  the  length  to  unroap  -  there  is  no  way  to  tell  the  Aegis  to  unmap  as  much 
as  was  mapped.  Storing  the  HID  of  the  active  heap  allows  quick  conversions  from  a  reference  for 
an  active  heap  to  the  HID  of  the  herp. 

The  idea  behind  the  activation  count  is  to  optimise  multiple  invocations  of  the  activate  primitive 
on  the  same  HID.  Such  multiple  invocations  do  not  result  In  the  heap  being  mapped  multiple  times. 
(Aegis  allows  this,  but  it  is  clearly  a  waste  of  address  space.)  Rather  all  activations  of  a  heap  other 
than  the  first  activation  simply  increment  the  activation  count  and  return  the  previously  allocated 
RHeap  object  for  that  heap.  A  table  translating  HIDs  into  RHeaps  allows  this;  only  one  RHeap 
object  is  ever  created  in  a  process  for  a  single  heap.  This  table  is  part  of  the  process  context  -  it 
resides  in  the  transient  heap.  Deactivating  a  heap  decrements  the  heap  activation  count.  When  the 
activation  count  drops  to  sero,  the  heap  is  unmapped. 

Encapsulating  RHeap Bs  In  RHeap*  allows  a  heap  to  be  moved  around  the  process  virtual  address 
space  simply  by  changing  the  RHeapB  slot  of  the  RHeap  associated  with  the  heap.  This  sort  of 
motion  is  neceseary  because  the  heap  is  mapped  for  a  particular  size,  and  when  it  needs  to  grow 
beyond  tbe  size  for  which  it  was  mapped,  it  must  be  unmapped  and  then  remapped,  and  there  is 
"no  guarantee  that  the  heap  will  be  mapped  into  the  same  spot. 
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Out  price  for  embedding  REeapBs  in  RHeaps  b  that  it  Adds  one  extra  memory  reference  (and 

probably  cm  extra  mac  Lice  instruction)  to  the  dereference  procedure:  given  an  RPeinter  and  an 
RBeap,  the  RHeapB  must  £rst  be  extracted  from  the  RHeap  before  an  object’*  virtual  address  can 
be  calculated.  The  cost  of  the  memory  reference  is  cot  a  great  concern  since  the  DOMAIN  hardware 
has  a  memory  cache;  we  can  safely  assume  that  for  multiple  dereferences  into  a  single  heap,  the 
RHeapB  of  the  that  heap  will  be  in  the  cache. 

The  issue  of  managing  the  process  virtual  address  space  is  one  which  we  have  not  pursued  extensively. 
We  rely  on  the  Ae^Ls  mapping  primitive  to  determine  where  to  map  heaps.  Its  allocation  strategy 
appears  to  be  adequate  for  our  purposes.  One  optimisation  we  could  easii y  make  is  to  not  actually 
unmap  a  heap  just  because  its  activation  count  has  dropped  to  sere.  We  could  keep  it  mopped  until 
the  address  space  became  full  and  some  hasp  that  isn’t  already  mapped  is  activated.  At  that  point 
we  could  unman  the  inactive  heaps  using  some  LRU  strategy.  This  optimisation  will  sometimes 
eliminate  the  coat  of  the  mapping  and  ur, mapping  operations.  One  reason  we  haven’;  adopted  the 
optimisation  is  because  (l)  it  hasn’t  proved  necessary,  and  (2)  it  raises  some  concurrency  problems: 
if  a  process  on  one  node  wants  to  activate  a  heap  that  is  inactive  but  still  mapped  into  a  process 
on  another  node,  it  will  be  unable  to  do  so. 

Another  poaibly  useful  address  space  management  technique  b  to  UEm«o  heaps  that  are  still  active, 
but  which  do  not  appear  tc  be  being  accessed.  Such  a  heap  could  be  unmapped  and  the  RE  cap  B  slot 
cf  the  Rheap  for  tbs  heap  could  be  modined  so  that  references  through  it  would  cause  aa  addressing 
error.  The  error  could  be  trapped  by  Old  and  the  heap  re-mappcd.  This  technique  would  be  useful 
if  a  process  needed  to  have  multiple  large  heaps  simultaneously  active.  This  b  especially  true  it 
the  present  DOMAIN  24  bit  addressing  environment.  With  an  address  space  of  4G  byte  {S2  bit 
address),  it  b  not  dearly  as  important. 

3.4.5  OM  heaps  hi  T 

OM  uses  some  knowledge  about  tbe  ‘internals  of  T  in  order  to  make  OM  heaps  accessible  to  T 
procedures.  To  T,  RHeapB*  appear  to  be  T  extends;  Le.  references  to  Rlieap Ss  are  extend- type 
references.  With  the  T  type  field  masked  to  seros,  an  RHeapB  reference  is  the  starting  address 
of  a  mapped  heap.  Note  that  this  address  b  outside  of  the  transient  heap  and  hence,  from  Ts 
perspective,  the  RHeapB  reference  b  invalid.  (For  a  reference  to  be  valid  to  T,  when  viewed  aa  aa 
address,  the  reference  must  be  to  a  part  of  the  address  space  where  the  current  transient  heap  b 
mapped.)  Fortunately,  the  invalidity  doesn't  matter.  The  only  potential  serious  source  of  problem 
might  be  the  T  garbage  collector.  However,  when  the  garbage  collector  encounters  an  apparently 
invalid  pointer,  it  simply  copies  the  pointer  to  the  new  transient  heap  and  does  not  follow  it. 

Another  small  problem  b  that  T  expect*  to  see  a  template  pointer  in  the  first  cell  of  an  extend. 
Clearly  it  b  not  possible  to  embed  a  T  template  pointer  into  an  OM  heap  -  it  would  violate  the 
process  context  and  position  independence  properties  of  the  heap.  But  not  filling  in  the  template 
pointer  slot  causes  no  problems  unless  *u  operation  b  applied  to  the  RHeapB  reference;  in  no  other 
cane  does  T  refer  to  the  template  pointer  slot. 

Since  OM  heaps  appear  to  T  to  be  extends,  a  cell  from  an  OM  heap  can  be  accessed  using  EXTEND* 
ELT,  the  T  primitive  for  accessing  %  cell  in  sn  extend.  The  lowest  level  OM  procedures  use  EXTEND* 
ELT. 


3.4.0  Summary  of  heap  faature* 

Having  described  the  implementation  properties  of  heaps,  let  us  review  why  the  heap  approach 
makes  sense. 

Heaps  are  position  independent.  Since  heaps  never  contain  any  machine  addresses,  heaps  can  be 
mapped  into  any  part  of  a  process’s  virtual  address  space  without  any  relocation  being  required. 
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Relocation  is  undesirable  because  it  is  time-consuming  sad  makes  it  impossible  to  share  the  heap 
between  multiple  processes. 

Hespe  take  advantage  of  clustering  properties  in  configurations  of  objects  (Le.  data  structures). 

Eeaps  take  advantage  of  DOMAIN  paging  facilities.  Only  those  disk  pages  of  heaps  that  contain 
objects  that  are  actually  referenced  are  transferred  from  the  disk  into  main  memory.  This  transfer 
is  the  responsibility  of  the  Aegis  paging  system. 


3.5  Intra-heap  references 

OM  extends  T  with  a  set  of  procedures  that  take  RPointers  and  RHeape  as  arguments.  These 
procedures  fall  into  two  general  categories:  allocston  and  seesssors. 

An  allocator  creates  a  new  OM  object.  An  OM  object  is  a  contiguous  piece  of  an  OM  heap.  The 
slots  of  the  object  can  contain  immediate  values  or  references  to  other  OM  objects.  An  allocator 
takes  at  least  two  arguments  -  the  heap  in  which  the  object  is  to  be  allocated,  and  the  type  of  the 
new  object.  An  allocator  may  take  additional  arguments  which  specify  things  like  the  initial  values 
of  parts  of  the  object.  In  terms  of  the  OM  implementation,  an  allocator  takes  at  least  one  Rlleap 
argument  and  returns  an  RPointer.  In  terms  of  the  OM  interface  that  the  programmer  sees,  the 
allocator  returns  an  OM  object. 

An  accessor  retrieves  or  modifies  a  slot  in  an  OM  object.  In  terms  of  the  OM  implementation,  an 
accessor  takes  at  least  one  RHeap  argument  and  one  RPointer  argument  and  returns  an  RPointer. 
In  terms  of  the  OM  programmer  interface,  an  accessor  takes  an  OM  object  and  returns  an  OM 
object. 

An  RPointer  and  an  RHeap  argument  taken  together  form  one  logical  argument  that  refers  to  one 
object.  Thus,  for  simplicity  we  will  sometimes  say  that  such  procedures  take  “RPointer/RHeap 
arguments*.  Also,  ere  say  that  some  pair  of  variables  S/1  refer  to  an  object  if  S  is  a  variable 
whose  value  is  an  RPointer  to  an  object  in  a  heap  that  is  referred  to  by  1.  Since  we  are  describing 
the  OM  implementation,  we  tend  to  say  that  a  procedure  takes  an  RPointer/ R  ‘leap  end  returns  an 
RPointer.  However  it  is  important  to  note  that  RPointer*  are  an  artifact  of  the  CM  implementation. 
The  programmer  who  uses  OM  thinks  of  the  procedure  as  taking  or  returning  &n  OM  object. 

3.5.1  Active  objects 

Note  that  accessors  and  allocators  manipulate  only  objects  in  active  heaps.  'Ve  call  such  objects 
setfes  ol)tcU.  There  are  no  primitives  that  take  an  RPointer  and,  say,  a  HID  to  identify  a  particular 
object.  Access  to  an  object  in  this  way  would  be  very  inefficient.  Each  access  would  have  to  insure 
that  the  heap  referred  to  by  the  HID  is  active.  If  it  b  active,  the  associat'd  RHeap  would  have 
to  be  located;  if  it  is  not  active,  the  heap  would  have  to  be  activated.  Bui  would  the  heap  be 
deactivated  after  the  access  is  complete?  Clearly  activating  and  deactivating  around  each  access 
is  too  expensive.  The  set  of  active  heaps  might  be  treated  Eke  -tsgea  in  a  virtual  memory  system. 
Heaps  would  be  activated  and  deactivated  based  on  soma  usage  pattern. 

One  might  argue  that  we  have  brought  this  expense  on  ourselves.  That  is,  by  introducing  the 
notion  of  heaps  we  have  also  introduced  the  inefficiency  of  having  to  activate  and  deactivate  heap*. 
However,  in  any  system  that  deals  wi  h  disk  storage  these  problems  will  arise.  In  tbe  ideal  world 
accessing  tbe  disk  would  be  as  fast  as  accessing  main  memory  and  tbe  disk  could  be  treated  as  an 
enormous  flat  address  space.  Access  to  an  object  would  be  implemented  as  a  direct  fetch  of  tbe 
object’s  representation  from  tbe  disk.  In  tbe  real  world,  data  must  be  transferred  from  the  disk 
to  main  memory  in  large  chunks  if  access  is  to  be  efficient.  Viewed  in  this  way,  heap  activation  is 
■imply  tbe  preparation  for  bulk  disk  data  transfer.  No  system  can  avoid  this  kind  of  preparation. 

Ia  short,  we  feel  that  tbe  complexity  of  managing  heap  activation  a  better  left  to  a  higher  level 
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of  tit  system.  The  higher  levels,  having  s  notion  shout  the  logical  behavior  of  a  program,  will  be 
able  to  better  guess  when  a  heap  should  be  activated  and  deactivated.  At  tbs  low  level  of  primitive 
accessors  and  allocators,  activation  is  explicit  and  only  active  heaps  can  be  manipulated. 


3.5,2  Aa  example:  OTvI  pairs 


Let  as  consider  an  OM  pair  (also  known  as  a  *coni  cell*).  OM  pain,  are  8  bytes  long  -  enough  for 
2  slots.  The  procedure  ICCM3  create*  a  new  OM  pair  and  initialises  the  pair’s  slots.  ! 521*3  takas 
three  arguments:  the  REeap  of  tbs  heap  in  which  the  pair  is  to  be  allocated,  the  initial  contents  of 
the  first  slot  (called  the  car),  and  the  initial  contents  of  the  second  slot  (called  the  tir). 

Let  us  look  at  what  ICC  113  mast  do.  First,  it  must  allocate  space  from  the  heap.  For  every  builtia 
OM  type,  there  is  a  procedure  that  allocates  aa  object  of  that  type  and  does  nothing  to  the  contents 
of  the  object.  For  OM  pairs,  this  procedure  is  called  1PAIA-ALL0C: 

(BEHJI2  (1C3K3  PI  P2  2SA?) 

(LET  (CL?  (! PAIL- ALLOC  LEA?))) 

(orr  (ipaib-cab  bp  eea?)  pi) 

(OOT  ( 1PAIB-C0.T  *?  EEA?)  P3) 

P?)) 


ICOLS  calls  I  PAIS- AILC5  and  then  uses  the  OM  pair  sexasaors  to  iaitialis*  the  contents  of  the  the 
pair.  !  PAIS- ALLOC  uses  one  of  a  set  of  lew-level  procedures  that  manipulate  heap  contents  directly 
and  are  not  accessible  to  the  user  of  Old.  One  of  these  procedures  is  called  EICOA?-ALLOG. 

(CUBIC  (1PAIB- ALLOC  EEA?) 

Oasi-spoBrna  (asoap-alloc  hza?  2)  hiipaib-tag)) 

R2SAP-ALLDC  t*k««  an  RHsap  argument  and  a  number  of  cells  to  allocate  and  returns  an  integer 
oft*et  into  the  heap.  XAKE-&P0BTT2X  is  a  primitive  that  creates  an  RPoiater  (immediate)  object 
from  an  integer  offset  and  an  integer  value  for  the  RPo inter  tag  field. 

Before  allocating  space,  RHSAP-ALLCC  must  insure  that  there  is  room  in  the  heap.  Two  questions 
that  must  be  answered  before  allocation  can  happen: 

1.  Can  the  sise  of  the  heap  be  extended  without  extending  past  the  amount  for  which  the  heap 
is  currently  mapped? 

2.  If  the  answer  to  (1)  is  no,  should  the  heap  be  extended  or  garbage  collected? 

Every  OM  heap  has  a  heap  pointer  at  a  fixed,  known  location  within  the  heap.  The  heap  pointer 
is  used  just  like  the  the  T  transient  heap  pointer.  When  a  heap  is  activated,  it  is  mapped  for  its 
current  sit*.  (I>etermining  the  current  length  of  a  heap  does  not  require  mapping  the  first  page  of 
the  heap  for  the  sole  purpose  of  extracting  the  heap  length  field  from  the  heap.  This  is  bemuse  the 
length  can  be  obtained  from  the  file  length  maintained  by  Aegis.)  As  we  said  earlier,  the  actual 
amount  of  address  space  mapped  is  the  next  highest  multiple  of  S2K  bytes.  Thus,  the  heap  pointer 
can  typically  advance  some  before  the  heap  needs  to  be  remapped  for  a  larger  sise. 

The  process  of  remapping  for  larger  sites  continues  as  the  heap  expands  until  the  heap  grows  to  a 
specified  sise.  This  site  is  called  the  ktif  mix  which,  like  the  heap  pointer,  it  at  a  fixed,  known 
location  within  the  heap.  The  heap  max  is  a  settable  parameter  for  a  heap.  When  the  sise  of  a  heap 
reaches  the  heap  max  for  that  heap,  the  garbage  collector  is  invoked  to  reduce  the  sise  of  the  heap 
(we  will  discuss  garbage  collection  later).  It  is  up  to  the  application  programmer  to  divide  his  data 
in  such  a  way  that  heap  sises  do  not  grow  in  an  unbounded  way  (i.e.  that  when  a  heap  reaches  ita 
heap  max  that  it  is  not  because  the  heap  is  full  of  aaa-gaxbage). 

To  describe  JtHEAP-ALLCC’s  behavior  concretely:  it  compares  the  the  heap  pointer  plus  Vie  allocation 
request  to  the  length  for  which  the  heap  is  mapped.  If  there  is  room,  the  heap  pointer  is  simply 
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hewnmatod.  If  then  is  not  room  but  the  heap’*  aiae  is  less  than  the  heap  max,  the  heap  is  remapped 
for  a larger  sine.  (Whik  remapping  k  expensive  relative  to  the  coot  of  incrementing  Ute  heap  pointer, 
remapping  happens  infrequently  compared  to  the  number  of  times  the  heap  pointer  is  incremented.) 
If  the  heap  max  is  reached,  the  garbage  collector  is  invoked. 

ITAIX-CAX  and  IPAIX-CDX  are  the  primitive  accessors  for  OM  pairs;  they  access  a  pair’s  ear  and 
cir  slots,  respectively.  In  the  context  of  the  SET  special  form,  these  accessors  modify  the  contents 
of  a  pair.  Let  us  consider  iPAIX-CCX  in  detail  ( 1PAXX-CAX  works  analogously).  tPAIS-CDS  takes  an 
RPointer  and  RHeap  argument  and  calls  iPCISTEX-EXAMIJE. 

(DETINE  ( IPAIX-CDX  ?  SEA?) 

(xpointtvexamine  p  heap  i)) 

The  XPOUTEX- . . .  procedures  arc  part  of  the  OM  implementation  and  are  not  available  to  appli¬ 
cation  programmers.  All  OM  objects  are  accessed  using  these  procedures  XPOINTEX-EXAJUNI  takes 
an  RPointer,  an  RHeap,  and  a  cell  index,  computes  the  total  offset  from  the  base  of  the  heap,  and 
calls  KXEAP-EXAMXXE. 

(DETINE  (XPOINTEX-EXAMINE  XP  H  I) 

(XHEAP- EXAMINE  H  (♦  I  (XP0INTEX-CADDX2SS  X?)))) 

XXEAP-ZXAMXHE  is  a  procedure  that  takes  an  RHeap B  and  an  integer  ceil  index  and  returns  the 
contents  of  the  specified  cell  of  the  heap.  IPOINTEV-CADDXESS  extracts  the  cell  number  part  of  an 
RPointer.  XHEAP- EXAMINE  is  just  another  name  for  EXTEND- ELT,  the  T  procedure  for  accessing  an 
element  of  an  extend  (recall  that  heaps  look  like  extends  to  T). 

All  the  procedures  mentioned  In  the  preceding  paragraph  are  tuUyraW*  *  so  that  there  is  no  pro¬ 
cedure  call  overhead.  OM  contains  no  explicit  machine  language  instructions.  It  relies  eoleiy  on  T 
primitives  and  the  T  compiler. 

The  T  compiler  compiles  CAX  into  2  88000  instructions  (3J  pace  oa  a  lOmHs  68000).  The  T  compiler 
compiles  1PAZX-CAX  into  14  instructions  (14.4  pane).  A  T  compiler  that  was  somewhat  smarter, 
but  still  had  no  built-in  knowledge  about  OM  procedures  could  reduce  that  to  7  instructions  (11.4 
psec),  X  of  which  were  simply  shifts  on  registers  (Le.  had  no  memory  operand).  There  is  an  ongoing 
effort  by  the  implementors  of  T  to  produce  a  new  T  compiler  that  can  produce  substantially  better 
code  than  the  current  T  compiler  (45),  and  we  expect  that  the  new  compiler  will  be  able  to  produce 
the  7  instruction  version. 


3.5.3  Arguments  to  OM  procedures 

OM’s  procedures  for  manipulating  OM  objects  are  modelled  after  Ts  procedures  for  manipulating 
T  objects.  The  major  difference  between  OM’s  and  IT’s  procedures  is  that  OM  procedures  take  one 
additional  argument  for  each  argument  that  refers  to  aa  object  in  a  heap.  This  extra  argument  is 
an  RHeap.  Some  OM  procedures  take  several  RPointer  arguments  and  only  one  RHeap  argument. 
Three  procedures  assume  that  all  the  arguments  refer  to  objects  in  a  single  heap  -  the  one  specified  by 
the  RHeap  argument.  Some  OM  procedures  take  one  RHeap  argument  for  each  RPointer  argument. 

The  fact  that  OM  procedures  require  these  extra  arguments  make  them  somewhat  inconvenient  for 
the  application  programmer.  We  will  pursue  this  issue  in  the  next  chapter. 


3.6  OM  types:  Introduction 

«  r 

As  in  the  T  type  system,  some  OM  types  are  identified  with  type  codes  and  others  with  the  extend 
mechanism.  The  following  types  have  reserved  type  codec 


*T»  terra  lor  procedures  whose  bodies  are  aubatltuted  Inline  at  the  call  portion. 
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•  Pair 

•  String 

•  Text 

•  Null 

•  Extend 

•  Type  ID 

•  Non-local  reference 

One  type  code  is  presently  unused. 


3.6.1  Non-^xtands 

We  have  already  discussed  pair*.  One  additional  item  about  pairs  is  that  they  are  often  chained 
together  by  their  cdn  to  form  a  list  of  pairs. 

Character  strings  are  implemented  in  two  parts.  An  object  of  the  text  type  is  a  fixed  length  vector 
of  characters  with  a  length  at  the  front.  An  object  of  the  string  type  is  a  reference  to  an  object  of 
the  text  type  plus  an  index  and  a  length  which  select  a  portion  of  the  text  object. 

The  null  type  is  a  set  containing  exactly  one  object  -  a dl  A'Wfs  major  function  is  to  mark  the  end 
of  a  list;  the  cir  of  the  last  pair  in  a  list  of  pair*  contains  a zIL 

In  addition  to  these  types,  ail  T  oojccta  that  are  represented  immediately  (e.g.  fixnums  and  charac¬ 
ters)  are  valid  OM  objects.  T  objects  that  are  not  represented  immediately  can  not  be  OM  objects 
because  their  representation  is  part  of  the  transient  heap. 


3.6.2  Sxtanda  and  type  identifier* 

The  extend  type  is  not  really  a  type  at  all  but  a  Sag  that  tells  OM  that  the  type  of  the  object  being 
referred  to  (called  the  txttnd)  is  determined  by  the  contents  of  the  first  slot  of  the  extend.  In  T, 
this  slot  contains  a  reference  to  the  handler,  the  object  code  object  that  implements  operations  on 
objects  containing  that  reference.  In  both  T  and  OM  extends  are  used  to  represent  all  objects  of 
user-defined  type.  Since  O.M  can  not  store  object  code  in  heaps,  we  need  some  way  of  indirectly 
referring  to  an  object’s  handler.  Even  if  we  could  store  object  code  in  heaps,  we  might  still  want 
this  level  of  indirection. 

We  have  already  explained  why  it  is  difficult  to  include  object  code  in  OM  heaps  and  why  we  have 
decided  that  all  object  code  resides  in  the  transient  heap.  However,  it  is  not  possible  to  refer  to  an 
object  in  the  transient  heap  from  an  object  in  an  OM  heap.  The  contents  of  the  transient  heap  are 
specific  to  a  single  process.  If  we  were  to  put  a  reference  to  a  transient  heap  object  into  an  OM 
heap,  the  OM  heap  would  not  be  free  of  dependencies  upon  a  particular  process  Thus,  we  can  not 
make  the  first  slot  of  an  ext/nd  pointer  to  object  code  that  resides  in  the  transient  heap.  Since 
extends  reside  inside  heaps  and  the  object  code  that  supports  extends  reside  outside  heaps,  it  is 
necessary  to  have  a  mechanism  for  finding  something  outside  a  heap  from  something  inside  a  heap. 
This  mechanism  must  rely  on  some  data  structure  that  is  not  tied  to  a  process's  context. 

OM  has  objects  of  type  type  identifier  for  identifying  the  type  of  an  object  without  reference  to 
an  object  in  the  transient  heap.  Type  IDs  are  represented  immediately  in  the  upper  2fl  bits  of 
RPointer*.  Type  ID*  are  simply  integers  in  the  range  jO.,23*  —  l).  Each  type  ID  identifies  some 
type  -  ultimately  some  piece  of  code  that  implements  operations  on  objects  of  the  type.  "Unlike  T’s 
template  pointers  (which  can  be  considered  a  type  ID  of  sorts  since  template  pointer*  define  how 
objects  respond  to  operations),  type  IDs  are:  (X)  not  direct  pointer*  to  object  code,  and  (2)  ere 
presented  to  the  application  programmer.  A  type  ID  is  an  indirection  mechanism  that  allows  the 
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specification  of  an  extend’*  type  to  be  separate  from  tbe  object  code  that  implement*  operation  on 
the  object.  Type  ID*  we  stored  is  tbe  first  cell  of  OM  extends. 

Extend  type*  come  in  two  varieties:  primitive  sad  user-defined.  Primitive  extend  types  sre  extend 
type*  about  which  OM  has  built-in  knowledge.  Vector*  are  examples  of  primitive  extend*  (i.e. 
object*  of  tome  primitive  extend  type).  The  essential  property  of  primitive  extend  types  is  that 
their  type  £D  is  fixed  and  unowj  by  OM.  The  handlers  for  primitive  extend*  are  built  in  to  CM. 
We  will  discus*  uaer-defia  types  lata-. 

3.7  Inter-heap  references 

The  previous  two  sections  have  dealt  with  the  issues  of  objects  within  a  single  heap.  This  section 
deals  with  the  mechanisms  that  allow  objects  to  refer  across  heaps. 


3.7.1  Non-local  references  and  garbage  collection 

An  OM  object  can  be  completely  identified  by  identifying  the  heap  in  which  the  object  resides  and 
the  particular  object  within  the  heap.  As  discussed  in  section  3.4.3,  heaps  are  named  with  heap 
identifiers  -  HID*.  Given  a  HID,  we  can  identify  an  object  within  tbe  heap  named  by  that  HID  with 
an  RPointer.  Thus,  it  seems  that  a  HID,  RPointer  pair  can  be  the  non-local  reference  discussed  in 
section  3.3.4. 

However,  this  scheme  is  not  adequate  since  it  makes  tbe  independent  garbage  collection  of  heaps 
impossible.  Independent  garbage  collection  requires  that  it  is  possible  to  identify  all  the  objects 
that  are  referred  to  by  other  objeeta.  la  general,  non-local  references  to  an  object  appear  outside 
the  heap  that  contains  the  object.  Thus,  given  the  present  scheme,  in  order  to  garbage  collect  a 
single  heap,  all  heaps  most  be  examined  to  see  if  they  contain  sen-local  references  to  objects  in  the 
heap  being  garbage  collected.  Scanning  all  tbe  heaps  to  find  references  into  the  heap  being  garbage 
collected  would  be  nearly  as  expensive  as  garbage  collecting  all  the  heaps  and  as  a  result  we  could 
not  consider  the  garbage  collector  aa  capable  of  garbage  collecting  heaps  independently. 

To  garbage  collect  heaps  independently  it  is  not  necessary  to  know  eakrre  tbe  non-local  references 
to  objects  in  the  heap  being  garbage  collected  are,  only  Uut  soch  non-local  references  exist  and 
to  what  they  refer.  At  garbage  collection  time,  knowing  that  the  sen-local  reference*  exist  need 
not  require  finding  all  the  non-local  references  aa  long  as  every  time  such  a  reference  is  formed, 
that  fact  is  recorded  some  place  easily  accessible  to  the  garbage  collector.  That  is,  that  when  a 
non-local  reference  is  formed,  an  entry  is  made  in  a  special  part  of  the  heap  containing  the  object 
being  referred  to.  We  call  this  part  of  the  heap  the  keep  index. 

The  heap  index  is  a  vector  of  RPointer*  to  all  the  ob  jects  inside  the  heap  that  are  referred  to  by 
non-local  reference*  outside  the  heap.  Tbe  sise  of  a  heap’s  index  is  fixed  at  the  time  the  heap  is 
created.  We  call  tbe  process  of  adding  an  RPointer  to  the  heap  index  export  in  f.  A  reference  count 
is  associated  with  each  RPoiutar  in  the  index.  The  reference  count  indicates  bow  many  non-local 
references  are  using  that  dement  in  the  index  If  tbe  reference  count  for  an  element  is  s *ro  then  tbe 
element  is  considered  to  be  free  -  it  can  be  used  tbe  next  time  an  RPointer  needs  to  be  exported. 

Garbage  collecting  a  heap  consists  simply  of  following  all  the  reference*  leading  from  objects  in  tbe 
heap  index.  All  objects  found  by  this  procedure  are  copied  into  a  new  heap.  Once  all  the  objects 
are  copied,  the  eld  heap  can  be  deleted.  Note  that  tbe  entry  la  tbe  HID  heap  (translating  HID*  to 
DOMAIN  file  names  or  file  UIDs)  must  be  updated  to  reflect  tbe  fact  that  the  heap  is  backed  by  a 
new  file.  We  will  discuss  more  of  tbe  details  of  garbage  collection  in  tbe  next  section. 

The  heap  index  allows  the  non-garbage  in  a  heap  to  be  identified.  However,  a  problem  still  remains: 
in  general,  after  garbage  collection  the  offsets  of  tbe  non- garbage  objects  have  changed.  Thus  any 
non-local  references  in  other  heap*  will  bv  wrong.  To  solve  this  problem  in  the  present  non-local 
reference  scheme  requires  that  the  garbage  collector  can  find  and  fix  all  the  non-local  references  to 
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Figure  3.4:  Sketch  of  the  garbage  collector 

the  heap  being  garbage  collected-  However,  if  we  modify  the  format  of  non-local  reference*,  we  can 
avoid  the  problem. 

Let  a*  change  the  format  of  aon-loctl  references  to  contain  a  HID  and  a  heap  index  offset,  rather 
than  a  HID  and  an  RPointer.  A  heap  index  offset  is  an  integer  that  identifies  a  particular  element 
of  a  heap  index.  We  call  these  non-local  references  LPainitit  (the  “L*  is  for  “long*).  As  a  part 
of  garbage  collection,  the  index  is  copied  from  the  old  heap  to  the  new  heap,  all  the  elements  of 
the  index  being  modified  to  contain  the  new  positions  of  objects  referenced  from  the  index.  Since 
LPointers  refer  to  objects  indirectly  through  the  heap  index,  aad  because  the  garbage  collector  has 
insured  that  the  elements  of  the  index  refer  to  the  same  objects  they  did  before  garbage  collection, 
the  LPointers  do  not  need  to  be  modiSed. 

Figure  3.4  contains  a  sketch  of  the  garbage  collector.  The  garbage  collector  performs  a  tree  walk  of 
all  toe  objects  in  the  heap.  The  heap  index  is  the  root  of  the  tree.  When  an  atom  (leaf)  is  reached, 
its  contents  are  simpiy  copied  L  to  the  new  heap.  For  an  internal  node,  a  node  is  created  in  the  new 
heap.  The  new  node’s  slots  are  filled  with  the  values  oi  recursively  applying  th*  garbage  collector 
to  all  the  old  no  i*’:;  slot*. 

Note  that  for  the  purpose*  of  the  above  sketch.  LPointers  ere  etom*.  That  is,  the  garbage  collector 
tree  walk  does  not  follow  LPointerr  to  objects  in  other  heaps.  The  point  of  our  scheme  is  to  allow 
heap*  to  be  garbage  collected  independently,  not  to  garbage  collect  all  heaps  at  once. 

How  is  the  heap  index  maintained?  So  far  all  we’ve  said  ia  that  when  a  LPointer  is  formed,  an 
entry  is  made  in  the  heap  Index;  the  entry  contains  an  RPointer  to  the  object  which  the  LPointer  is 
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to  identify.  What  happens  when  the  object  that  refers  to  the  LPointcr  becomes  garbage?  At  that 
point,  the  LPointcr  becomes  garbage.  When  all  the  L Pointers  that  name  a  particular  heap  index 
element  become  garbage,  then  the  object  referred  to  by  the  RPointer  in  the  heap  index  elements 
becomes  garbage  too.  Garbage  collection  as  we’ve  described  it  doesn’t  do  anything  about  garbage 
LPointcr*  and  there  is  no  mechanism  for  deallocating  elements  of  the  heap  index. 

Our  goal  is  to  free  elements  of  the  heap  index  when  all  the  LPointer*  that  are  using  an  element 
becomes  garbage.  To  do  this  we  modify  the  garbage  collector  so  that  after  all  the  non-garbage 
has  been  copied  from  the  old  heap  to  the  new  heap,  all  the  garbage  LPointers  in  the  old  heap  are 
examined.  For  each  garbage  LPointer,  the  reference  count  of  the  index  element  of  the  heap  referred 
to  by  the  LPointer  is  decremented  by  one.  When  the  count  reaches  sero,  the  space  occupied  by  the 
object  that  is  no  longer  referred  to  by  any  LPointers  is  not  reclaimed  -  the  space  is  reclaimed  only 
when  the  heap  containing  that  object  is  itself  garbage  collected.  At  that  time  since  the  object  is 
no  longer  referred  to  from  the  index,  the  object  will  not  be  copied  into  the  new  heap  and  the  space 
is  thus  reclaimed  (assuming  the  object  that  is  not  referenced  from  the  index  is  also  not  referenced 
from  some  non-garbage  object  in  the  heap). 

To  be  able  to  traverse  all  the  garbage  LPointers  at  the  end  of  garbage  collection,  it  must  be  possible 
to  find  all  the  LPointer*  in  a  heap.  This  can  be  achieved  by  maintaining  a  linked  list  of  LPointers 
whose  root  is  at  some  fixed  place  in  the  heap.  Traditional  garbage  collection  techniques  require  one 
to  be  able  to  determine  whether  an  object  has  been  copied  out  already.  Thus,  at  the  end  of  garbage 
collection,  this  list  can  be  traversed  and  any  LPointers  that  have  not  been  copied  to  the  new  heap 
are  garbage  and  the  procedure  described  above  can  be  applied  to  them. 

Note  that  the  above  scheme  does  not  handle  circular  references  across  heaps.  For  example,  if  object 
A  in  heap  1  contains  a  reference  to  an  LPointer  to  object  B  in  heap  2,  and  object  B  contains  a 
reference  to  an  LPointer  to  object  A,  then  even  if  there  are  no  other  references  to  objects  A  and  B, 
then  the  space  occupied  by  A  and  B  will  never  be  reclaimed  by  the  garbage  collector.  In  general, 
only  by  garbage  collecting  a  set  of  heaps  at  once  can  the  circularly  linked  garbage  objects  in  that 
set  of  heaps  be  found  and  removed. 


3.7.2  LPointers  in  detail 

LPointers  must  be  large  enough  to  contain  a  HID  and  an  offset  inW  a  heap  index.  Ideally,  LPointers 
would  be  represented  as  T  immediate  values  the  way  RPointers  are.  Unfortunately,  T  does  not 
have  any  more  spare  type  codes.  However,  it  is  worth  examining  the  packing  of  LPointers  into  T 
references  since  in  the  long  run  T’s  reference  format  might  change  to  allow  more  immediate  types. 

Are  32  bits  enough  to  hold  a  HID  and  an  offset  into  a  heap  index?  First  we  need  to  decide  whether 
HIDs  are  to  be  unique  for  all  time.  Unique  HIDs  allow  HIDs  to  be  explicitly  deleted.  If  HIDs  are 
unique,  reference  from  LPointers  to  the  contents  of  a  deleted  heap  can  be  detected  because  we  are 
guaranteed  that  the  HID  will  not  have  been  reassigned  to  another  heap.  While  we  argued  against 
using  UIDs  for  object  references  because  of  performance  problems,  since  the  frequency  at  which 
HID*  have  to  be  •dereferenced"  is  less  than  the  frequency  at  which  object  references  have  to  be 
dereferenced,  we  choose  to  use  UIDs  for  HIDs  because  of  explicit  deletion  capability. 

Having  decided  to  use  unique  HIDs,  we  must  be  fairly  generous  in  allocating  bits  for  HIDs.  It  is 
not  unusual  for  a  Moderate  size  timesharing  system  to  have  more  than  32K  files  (recuiring  IS  bits) 
at  s  tingle  instant  Over  the  lifetime  of  a  system,  the  total  number  of  files  created  can  be  presumed 
to  be  much  larger.  The  ideal  way  to  generate  UIDs  is  to  allocate  them  consecutively  as  they  are 
needed.  However,  this  requires  access  to  a  central  piece  of  data  '.Lat  bolds  the  next  UID  to  assign. 
To  avoid  this  centralization,  UID  generation  schemes  typically  embed  a  processor  ID  in  the  UID 
and  let  each  processor  pick  its  own  local  part  of  the  UID.  Since  the  size  of  the  processor  ID  is  fixed 
and  determined  by  how  many  processors  are  expected  to  ever  exist,  this  generally  increases  the 
number  of  bits  that  must  be  allocated  to  the  whole  UID.  Also,  since  it  is  desirable  that  UIDs  are 
in  fact  reliably  unique,  UID  generation  schemes  typically  use  a  monotonically  increasing  hardware 
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clock  u  part  of  Ike  UID.  Since  the  resolution  of  the  clock  roust  be  small  enough  to  allow  two  UIDs 
generated  back-to-back  to  be  ,«*":qi!e,  the  number  of  bits  assigned  to  the  clock-based  part  of  the  UID 
is  typically  large.  DOMAIN  UIDs  are  generated  using  essentially  the  scheme  described  above 
and  are  &4  bits  in  length. 

Sven  if  we  were  fairly  miserly  in  our  allocation  of  bits  to  HIDa,  it  seems  anilkely  that  we  could  be 
miserly  enough  so  a*  to  be  able  to  pack  both  a  HID  and  a  hasp  index  offset  into  lea  than  32  bits. 

In  choosing  the  format  of  LPointers,  once  we  decide  that  LPolnUrs  can  not  be  made  to  fit  within 
a  normal  sized  (i,«.  local)  reference,  our  options  are  less  constrained:  the  format  of  nr  OiC.tc3*3 
can  be  chosen  to  be  what  teems  logically  correct,  not  amply  what  can  be  packed  into  a  small 
place.  However,  this  freedom  has  a  price.  T  (and  Old)  procedures  pass  and  return  fhted-me 
references;  there  is  no  provision  for  passing  and  returing  aggregate*  (objects  with  non-imiaadiate 
representations).  Thus,  ail  aggregates  must  be  allocated  in  the  heap.  Heap  allocation  is  not  free  - 
the  more  heap  allocated  objects  there  are,  the  more  expensive  garbage  collection  becomes. 

We  chose  LPointers  to  be  2  cells  (8  bytes)  long.  The  first  cell  contains  a  HID  and  the  second  contains 
the  heap  index  offset.  Since  the  heap  allocation  granularity  is  8  bytea,  it  would  not  have  made  sense 
to  have  a  more  compact  LPointer.  There  can  no  doubt  that  one  cell  is  sufficient  to  hold  the  index 
offset.  Given  our  model  of  the  uee  of  heaps  -  that  data  structures  are  partitioned  bo  that  most  of 
the  references  are  between  objects  la  the  same  heap  -  fr3  incoming  references  is  certainly  sufficient. 

That  4  bytes  are  sufficient  to  hold  s  HID  is  more  open  to  question.  It  is  certainly  vtiongh  given 
OM’i  present  scheme  for  generating  HEDt  -  consecutively  and  based  on  a  renirsi  count  held  in 
the  HID  heap  -  but  we  do  not  expect  that  this  scheme  would  be  used  in  a  production  version  of 
OM  because  of  the  problems  discussed  above.  Other  tyrterss,  like  the  DOMAIN,  that  uae  UIDs 
generally  are  more  liberal  in  their  allocation  of  bit*  to  UIDs.  OM’*  design  does  not  preclude  the  use 
of  larger  HIE1*.  In  the  current  implementation  cf  OM,  as  an  aid  to  debugging,  both  the  index  offset 
and  the  HID  are  represented  as  T  Fixnuraa,  thus  reducing  the  number  of  incoming  LPointers  and 
the  number  of  heaps  to  2s4.  There  is  no  reason  why  then*  values  could  not  be  Ml  32-bit  integer*. 

LPointer*  are  a  type  of  OM  object.  They  can  be  manipulated  by  OM  procedures  that  are  available 
to  the  OM  programmer.  Note  that  this  makes  LPointer*  different  from  RPointers,  which  are  an 
artifact  of  the  OM  impJemtnUiwn  and  in  principle  are  of  no  more  business  to  the  014  programmer 
than  axe  addresses  to  the  T  programmer. 

Figure  3.5  diagrams  a  slot  of  an  object  that  contains  a  reference  to  an  object  La  another  heap. 

3.7.3  Making  LPointsr* 

LPointers  are  made  with  the  IEXP0RT-8P0IMTER  procedure.  This  procedure  takes  an  RPointer/- 
RHeap  Vo  specify  some  object  to  be  exported.  It  also  tike*  another  RHeap  argument  to  specify 
in  what  heap  the  LPointer  is  to  be  allocated.  The  procedure  returns  (an  RPointcr  tc)  a  newly 
allocated  LPointer. 

(define  ciEXPOST-RPOirnra  a?  heap  to-eeap) 

(LET  (CELT  (RHEAP- ALLOC- IMDEX-ELT  t?  HEA?)>) 

(IF  (SOT  ELT) 

(ERROR  "can't  allocate  index  eieasnt")) 

(MAKE- I LP0IHTE1  TO-BEA?  0t3EAP-lID  EEAP)  ELT))) 

I  EXPORT- RPOISTZX  uses  the  RHeap  primitive  RHEAP -ALLOC -INDEX -ELT  to  allocate  and  initialise  a 
slot  in  a  heap  index.  RHERP-ALLCC-ISDEX-ELT  returns  the  integer  offset  of  the  slot  in  the  index. 
MAKE- 1LP0IMTER  allocate*  an  LPointer  in  the  heap  specified  by  the  first  argument  and  initializes 
the  two  slots  of  the  LPointer  Vo  the  second  and  third  arguments  respectively.  The  newly  created 
LPointer  is  added  to  the  TO -HEAP’S  list  of  LPointers  contained  within  TO -HEAP.  Note  that  we  take 
advantage  of  the  fact  that  we  store  the  HID  in  the  RHeap  structure  (RKEAF-HID  extracts  the  IUD 
field  from  the  RHeap  structure). 
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Figure  3.5:  An  inter-hoop  reference 


In  the  current  version  of  OM,  RHXA?*ALLOC-IHDEC-ELT  is  not  terribly  smart.  It  simply  scans  the 
heap  index  looking  for  on  element  whose  reference  count  is  tero.  The  process  of  finding  a  free  index 
element  could  certainly  bo  optimised.  For  example,  we  could  link  together  oil  the  free  entries. 

The  procedure  lEXPORT-lMirm-wrra-EXISTIliO-IXDEX-EiT  is  similar  to  I ETPORT-RPOINTER  ex¬ 
cept  that  it  requires  the  RPointer  passed  to  it  already  frc  press**  fa  tkt  keep  index.  If  the  RPointer 
is  found  in  the  index,  the  appropriate  reference  count  is  increased  by  one  and  the  index  offset  is  used 
in  the  newly  created  LPointer.  If  the  RPointer  is  not  found  in  the  index,  the  procedure  behaves  just 
like  lEXPORT-RPOirm.  The  idea  behind  lEXPORT-WOIirrat-SITH-EXISnKC-IBDEC-ELT  is  that  St 
is  desirable  that  multiple  LPciniers  to  the  same  object  share  the  same  index  element.  That  way 
the  sise  of  the  index  can  be  minimised.  If  an  application  program  knows  that  an  object  it  is  ex¬ 
porting  is  not  already  in  the  index,  St  can  use  1  EXPORT- RPOIKTZR  which  does  not  require  the  index 
to  be  scanned  (assuming  the  optimised  version  of  RHEAP-ALLOC-IKDEX-ELT.  Otherwise  it  must  use 
HXPORT-RPOIMTER-WrTH-£XISTI)K}-IKDEX“ELT 

Recall  that  in  our  initial  discussion  of  non-local  reference  in  section  3.3.4  we  pointed  out  that  it 
would  be  necessary  to  have  a  bit  to  distinguish  local  references  to  local  objects  from  local  references 
to  non-local  references.  It  should  now  be  clear  that  this  bit  becomes  available  simply  by  virtue  of 
our  type  taj  scheme.  One  of  the  RPointer  type  codes  is  used  to  indicate  a  reference  to  an  LPointer. 


3.7.4  Dereferencing  LPointer* 

OM’t  primitive  procedures  manipulate  active  objects.  The  procedures  taka  one  or  more  RPoint¬ 
er/ R  Heap  arguments  to  indicate  what  objects  are  to  be  manipulated.  LPointer*  can  refer  to  any 
object,  active  or  not.  Thus,  in  general,  given  an  LPointer  to  an  object,  it  is  first  necessary  activate 
the  object.  This  conversion  results  in  an  RPointer/RHeap  that  refers  to  the  now-active  object  and 
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can  be  used  to  manipulate  the  object. 

The  procedure  !  LPOIFTSS-COSTEUTS  takes  an  RPoiater/RHeap  to  an  LPointer  (recall  that  LPointm 
are  themselves  OM  objects)  and  returns  an  RPointer  to  the  object  referred  to  by  the  LPointer. 
Note  that  the  returned  RPointer  can  be  interpreted  only  in  the  context  of  the  heap  identified  in  the 
LPcinter. 

L?OIHTEl-COHTE»rS  is  defined  ns: 

(define  (iLPOiTrnt-ccti'rrrrs  l?  eea?) 

(XH2AP-IKDEX-3.7-VAU3E  (SI3»RI2U?  (ILPOISm-EID  L?  E2AP)) 

( 1 LFCIKT28-IUD2X  IP  EZA?)}) 

Let  us  examine  ii  in  some  detail.  ILTQINTEIl- INDEX  and  !L?OINTES-HID  are  the  accessors  for 
LPointer  objects.  ILPQIX7EX-3ID  returns  the  BID  field  of  an  LPointer,  ILFSIifTSS-INSEC  returns 
the  index  offset  field  of  an  LPointer. 

HID-riUItAP  takes  a  HID.  and,  if  the  heap  named  by  the  HID  is  active,  returns  the  RHwp  for  the 
active  heap;  if  the  named  heap  is  not  active,  the  procedure  returns  false.  Note  that  before  calling 
1 L?  C I  inn-  CD  NTZNTS  the  heap  referenced  by  the  LPointer  argument  to  !  LFOINTZil-CCNTElITS  must 
have  been  activated;  e.g.  by  executing*. 

(aCTTVATS-EZAP  (1LP0IXTS2-HID  L?  EZA?)) 

StHEAP-IND£X-£I.T-VALUS  returns  the  RPointer  at  the  specified  offset  into  the  specified  active  heap’s 
index. 

Suppose  a  variable  contains  (an  RPointer  to)  an  LPointer  to  a  pair.  The  following  procedure  returns 
the  edr  of  the  pair. 

(DEFINE  ( IPAIR-CAA-VIA-LNOINTEX  L?  HEAP) 

(ipair-cdr  (iLPCiHTEa-co:;~:rrs  l?  heap) 

(ACTIVATE- HEAP  (ILPOISTSR-HID  L?  HEAP)))) 

3.7.5  Comparison  with  Bishop’s  ORSLA 

Bishop’s  thesis  [14)  describes  ORSLA,  a  system  that  is  in  some  ways  similar  to  ours.  ORSLA 
depends  on  special  hardware;  neither  the  hardware  or  software  was  actually  built.  ORSLA  has 
areas  which  correspond  to  OM  heaps.  ORSLA  has  only  one  kind  of  reference.  However,  to  enable 
the  independent  garbage  collection  of  areas,  all  references  between  areas  go  through  inier-srea  links 
(LALs).  IALs  are  special  objects  understood  by  the  hardware.  The  hardware  makes  a  reference  to 
an  IAL  appear  to  be  to  the  object  to  which  the  IAL  refers.  IALs  are  similar  to  OM’s  LPointers 
except  that  IALs  contain  actual  object  references,  not  something  like  LPointer’s  offset  into  a  table 
of  object  references. 

Each  area  has  two  distinguished  lists:  a  list  of  all  IALs  inside  the  area,  and  a  list  of  all  IALs  outside 
the  area  that  refer  to  objects  inside  the  area.  The  first  list  contains  outgoing  IALs  and  the  second 
list  contains  incoming  IALs  (these  terms  are  with  respect  to  a  particular  area).  Since  every  IAL  is 
both  inside  some  area  and  pointing  into  some  other  area,  every  IAL  is  on  two  lists.  The  root  of  the 
ORSLA  garbage  collection  of  an  area  is  the  list  of  incoming  IALs. 

Since  ORSLA  has  a  single  form  of  reference,  it  is  conceivable  that  IALs  could  be  placed  in  the  area  of 
the  object  to  which  the  IAL  refers  instead  of  the  area  of  the  object  that  contains  the  reference  to  the 
IAL.  However,  as  Bishop  notes,  this  would  make  it  impossible  to  garbage  collect  areas  independently 
since  when  the  IAL  moved  as  a  result  of  its  being  in  a  heap  that  was  being  garbage  collected,  the 
reference  to  the  IAL  from  the  object  in  the  other  heap  could  not  be  fixed. 

Note  that  in  OM,  the  analog  of  an  IAL  is  the  combination  of  an  LPointer  and  an  element  of  a  heap 
index.  That  is,  in  a  sense  we  have  a  two-piece  IAL,  naif  of  which  is  in  the  source  of  the  non-local 
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reference  end  half  of  which  is  in  the  target  of  the  non-local  reference.  Only  the  Utter  half  is  relevent 
to  the  garbage  collector.  That  this  piece  of  information  is  in  the  heap  being  garbage  collected, 
rather  than  in  some  other  heap,  is  important.  It  means  that  the  locality  of  reference  of  the  garbage 
collector  is  improved  -  it  doesn't  have  to  touch  all  the  heaps  in  which  non-local  references  to  the 
heap  being  garbage  collected  reside.  In  the  ORSLA  garbage  collector,  the  roots  of  the  garbage 
collector  are  spread  throughout  many  heaps,  all  of  which  have  to  be  touched. 

OM  does  have  a  locality  of  reference  problem  though:  at  the  end  of  the  garbage  collection,  if 
there  are  garbage  LPointers,  the  indexes  of  the  various  heaps  referred  to  by  the  LPointers  will 
have  to  be  modified.  Thus,  the  degree  of  non-locality  of  reference  in  OM  garbage  collection  is 
proportional  to  the  number  of  garbage  outbound  non-local  references.  The  degree  of  non-locality 
of  reference  in  ORSLA  garbage  collection  is  proportional  to  the  number  of  non-garbage  inbound 
non-local  references.  Which  system's  garbage  collector  has  the  better  behavior  (i.e.  minimizes 
the  amount  of  non-locality  of  reference)  can  be  determined  only  experimentally.  Note  that  OM’s 
garbage  collection  procedure  is  amenable  to  techniques  for  increasing  locality.  For  example,  the 
heap  indexes  might  be  stored  separately  from  the  heaps  themselves  Multiple  indexes  might  be 
packed  together  to  increase  the  locality  of  reference. 


3.8  Concurrent  access  to  heaps 

If  we  want  the  data  structures  stored  in  heaps  to  be  accessible  by  multiple  orocesses  running 
concurrently,  we  need  to  examine  what  techniques  need  to  be  used  to  assure  the  integrity  of  the 
data. 

In  this  section  we  will  consider  the  case  of  multiple  processes  running  within  a  single  physical  main 
memory  (i.e.  on  a  single  DOMAIN  node)  trying  to  concurrently  access  a  heap.  OM  does  not  allow  a 
single  heap  to  be  accessed  by  multiple  processes  that  are  not  sharing  a  single  physical  main  memory. 
Ynis  is  because  the  OM  implementation  uses  the  Aegis  file  mapping  primitives  and  these  primitives 
do  not  support  that  sort  of  concurrent  access. 


3.8.1  Controlling  concurrency 

The  correct  manipulation  of  certain  parts  of  a  heap  requires  that  a  single  process  have  exclusive 
access  to  the  heap  while  the  manipulation  is  happening.  Advancing  the  heap  pointer  is  an  example 
of  such  a  manipulation.  The  allocation  mechanism  must  be  able  to  get  the  current  value  of  the  heap 
pointer  and  then  increment  it  atomically.  Similarly,  the  heap  index  must  be  accessed  in  a  way  that 
insures  that  two  processes  do  not  obtain  the  same  index  element  as  a  result  of  exporting  an  RPointer. 
These  concurrency  problems  are  not  limited  to  the  parts  of  the  heap  that  are  examined  and  modified 
by  only  the  OM  implementation.  In  general,  application  programs  that  can  run  concurrently  on  the 
same  heap  need  to  control  access  to  objects  in  the  heap. 

Aegis  has  two  mechanisms  for  controlling  concurrent  access  to  data:  file  locking  and  eventcounts. 

File  locking  allows  a  process  to  map  a  file  in  a  way  that  restricts  the  way  other  processes  can  map 
the  file.  For  example,  a  process  can  map  a  file  for  read/write  access  and  lock  the  file  so  that  other 
processes  can  have  read  but  not  write  access  to  the  file.  File  locking  provides  fairly  coarsely  grained 
control  of  concurrency.  The  lock  is  set  when  the  file  is  mapped;  the  success  of  the  mapping  operation 
is  determined  by  what  locks  are  already  set  at  the  time  the  operation  is  executed.  Thus,  using-  the 
locking  mechanism  requires  the  process  to  re-map  the  heap  file  before  and  after  each  operation, 
or  set  of  operations  that  need  to  be  atomic.  Aegis  does  not  have  a  mechanism  for  automatically 
blocking  a  process  that  attempts  to  m&p  a  file  in  a  way  that  is  not  allowed  by  the  existing  locks. 
Thus,  the  process  would  have  to  ‘busy  wait",  re-trying  the  map  operation  periodically.  Clearly, 
this  overhead  would  be  unacceptably  high  for  operations  like  advancing  the  heap  pointer. 
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However,  file  locking  u  appropriate  when  the  lock  will  be  held  for  a  relatively  long  period  of  time  and 
the  expected  concurrency  is  low.  For  example,  in  a  mail  system,  there  is  a  possibility  for  concurrency 
in  the  accesses  made  by  the  program  that  adds  to  mail  to  a  mail  box  and  the  program  that  reads 
the  mail  box.  Each  program  can  map  and  lock  the  heap  for  the  duration  of  some  logical  operation. 
For  the  former  it  would  be  during  the  operations  that  constitute  adding  the  new  message;  for  the 
latter  it  would  he  during  an  operation  like  displaying  the  headers  of  all  the  messages  in  a  mail  box. 
These  durations  are  long  compared  to  the  duration  of  the  operation  of  advancing  the  heap  pointer. 
If  there  is  contention  for  the  heap,  it  is  acceptable  for  the  programs  to  b  isy  wait,  trying  to  map 
every  second  or  so.  The  user  won’t  notice  and  the  program  won’t  be  wa&tiag  CPU  cycles  too  much. 

Eventcounts  allow  processes  to  synchronise  at  a  finer  kvsl  and  with  less  overhead  than  with  file 
locking.  Eventcount?  are  equivalent  in  power  with  semaphore®.  All  processes  accessing  the  same 
part  of  a  heap  must  agree  to  obey  the  semaphore  associated  with  that  part  of  the  heap.  In  the 
case  of  application  related  data,  the  semaphore  can  be  referenced  from  the  object  whose  contents 
are  to  be  accessed  concurrently.  The  Aegis  eventeount  primitives  allow  a  process  to  block  until  the 
eventcount  indicates  that  the  process  has  exclusive  access  to  the  object. 

The  problem  with  eventcounts  is  that  they  introduce  overhead.  The  overhead  is  in  the  cost  of  the 
check  of  the  eventcount  before  vhe  data  can  be  accessed.  (This  check  1*  a  system  call  to  Aegis.)  In 
cases  where  it  is  appropriate,  the  file  locking  approach  has  less  overhead  because  no  checks  need  to 
be  made  before  each  access. 

A  special  case  that  we  expect  OM  needs  to  deal  with  is  concurrency  on  oa/y  the  OM-intramal 
parts  of  the  heap  (e,g.  the  bean  pointer  and  index)  and  not  on  an  application’s  object  inside  the 
heap.  Since  the  access  patterns  to  these  internal  data  structures  are  well  known,  it  is  reasonable 
that  concurrency  control  be  implemented  using  the  hardware  *iest-&nd-set*  instruction  and  busy 
waiting  since  we  know  that  the  process  will  never  have  to  wait  too  long.  Ideally,  the  busy  wait  loop 
should  include  a  call  to  the  operating  system  suggesting  that  it  select  another  process  to  run7.  As 
opposed  the  the  eventcount  approach,  in  this  approach  the  operating  system  call  happens  only  if 
the  resource  is  locked.  Thus,  with  a  resource  that  is  almost  always  unlocked  (e-g.  the  heap  pointer), 
the  test-and-set  approach  is  much  cheaper  than  the  eventcount  approach. 


3.8.2  Garbage  collection 

The  OM  heap  garbage  collection  procedure  we’ve  described  is  correct  only  if  no  processes  are 
manipulating  a  heap  when  the  garbage  collector  begins  processing  that  heap.  If  the  garbage  collector 
can  be  invoked  asynchronously  (e.g.  in  the  middle  of  an  object  allocation  primitive)  then  it  is  possible 
that  the  only  reference  (RPointer)  to  an  object  is  in  a  variable  on  a  process’s  execution  stack  (or  in 
a  register).  Since  the  garbage  collector  traces  objects  only  from  the  heap  index,  an  object  referred 
to  from  only  the  stack  will  be  discarded.  Also,  'in  general,  RPointers  on  the  stack  to  objects  that 
are  not  discarded  will  be  incorrect  after  the  garbage  collection  because  the  garbage  collector  may 
have  moved  the  objects. 

TVaditional  garbage  collectors  solve  the  problem  of  references  from  the  stack  by  putting  those  ref¬ 
erences  in  the  root  set  at  the  start  of  the  collection.  Unfortunately,  we  can  not  easily  use  this 
technique  because  it  is  not  possible  to  tell  what  heap  an  RPointer  on  the  stack  refers  to.  Without 
knowing  the  heap  associated  with  these  RPointer,  the  garbage  collector  can  not  trace  through  the 
RPointers  on  the  stack. 

There  is  no  easy  solution  to  this  problem.  The  current  implementation  of  OM  simply  does  not 
allow  the  garbage  collector  to  be  invoked  asynchronously.  This  restriction  is  severe  but  does  not 
make  the  current  implementation  unusable.  Not  being  able  to  garbage  collect  asynchronously  is  a 
problem  only  if  applications  are  creating  garbage  rapidly.  If  garbage  is  not  being  created  rapidly, 
the  rate  at  which  the  heap  needs  to  be  garbage  collected  is  low.  If  each  run  of  an  application  does 
not  create  a  lot  of  garbage,  it  is  a  reasonable  restriction  th#t  the  garbage  collector  can  be  invoked 


7Ur>fortunat«ly  Aegis  does  not  supply  the  necessity  functionality  to  do  this,  but  It  would  not  be  difficult  to  add. 
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only  between  (and  not  during)  runs  of  the  application.  Our  view  is  that  OM  heaps  are  used  for 
archival  storage,  not  intermediate  results  that  quickly  become  garbage.  Such  intermediate  results 
should  be  allocated  in  the  transient  heap. 

If  we  want  to  support  asynchonous  invocation  of  the  garbage  collector,  we  must  make  it  possible  for 
the  collector  to  determine  the  heap  associated  with  every  RPointer  on  the  stack.  For  each  RPointer 
in  a  stack  frame  (resulting  from  one  procedure  activation)  there  must  be  an  RE cap  that  is  associated 
with  that  RPointer  and  that  Rfieap  must  be  in  the  same  stack  frame  as  the  RPointer.  This  could 
fail  to  be  the  case  only  if  some  procedure  took  an  RPointer  argument  but  no  RHeap  argument.  But 
no  such  procedures  exist  because  such  procedures  could  not  do  any  useful  operation.  Since  a  single 
frame  can  contain  many  RPointers  and  RHeap*,  the  problem  for  the  garbage  collector  is  to  pair  up 
the  RPointers  with  the  RHeap*. 

With  sufficient  knowledge  about  the  way  the  compiler  lays  out  stack  frames  and  by  requiring  every 
RPointer  argument  to  be  followed  by  an  RHeap  argument  (or  by  adding  some  declarative  syntax 
that  achieves  the  same  effect)  it  would  be  possible  to  write  a  garbage  collector  which  could  deduce 
the  RPointer /RHeap  pairings  on  the  stack  and  hence  be  able  to  trace  references  to  OM  objects  from 
the  stack. 


3.9  Heap  structure  in  detail 

Figure  3.6  shows  the  actual  format  of  a  heap.  The  part  above  the  dashed  line  represents  the  transient 
heap.  E  is  some  variable  whose  value  is  (a  reference  to)  an  RHeap  structure  which  describes  some 
active  heap.  The  last  slot  of  the  RHeap  structure  is  an  RHeapB  which  to  T  appears  to  be  a  pointer 
to  an  extend  that  is  outside  the  transient  heap.  The  section  of  the  figure  below  the  dashed  line  is  a 
part  of  the  same  process’s  address  space  into  which  some  heap  is  mapped. 

Note  that  the  RHeapB  from  the  RHeap  b  actually  a  pointer  to  the  fourth  cell  of  the  heap.  Thu  is 
because  T’s  convention  for  extend  references  b  that  the  reference  points  to  the  first  data  cell  of  the 
extend  -  Le.  the  slot  following  the  T  template  pointer.  To  T,  heaps  appears  as  vector- 1 vat  extend*. 
A  vector-type  extend  b  an  extend  that  has  a  length  cell  before  the  template  pointer.  Vector-type 
extends  are  used  to  implement  Lisp’s  traditional  vector  of  references.  Vector- type  extends  are  also 
used  to  implement  byte  vector*  and  tit  vector*.  During  the  debugging  of  OM,  we  were  able  to  set 
the  template  pointer  slot  of  the  heap  to  point  to  the  byte  vector  template  in  the  transient  heap. 
This  enabled  us  to  use  the  T  standard  byte  vector  primitives  for  examining  the  heap. 

The  heap  has  two  major  sections;  the  header  and  the  data  sections.  The  header  contains: 

Beep  pointer:  The  cell  number  (i.e.  offset  from  the  base  of  the  heap)  of  the  first  free  cell  in  the 
heap. 

Me*  keep  pointer:  The  maximum  value  the  heap  pointer  should  be  allowed  to  reach.  When  RHEAP- 
ALLOC  notices  that  the  heap  pointer  has  reached  this  value,  the  garbage  collector  b  invoked. 

Heed  of  LPointer  list:  The  head  of  the  list  of  LPointers  contained  within  thu  heap. 

Site  of  index:  Maximum  number  of  elements  in  the  heap  index. 

Index  elements:  Vector  of  RPoirters  and  reference  counts. 

Dote  cells:  Section  in  which  OM  objects  are  allocated. 

The  heap  pointer  b  initialised  to  the  cell  number  of  tbe  first  data  celL  IB  ZAP -ALLOC  uses  and 
increments  tbe  heap  pointer.  Note  that  tbe  offset  part  of  an  RPointer  b  the  offset  from  the  base 
of  the  heap,  so<  tbe  offset  from  tbe  beginning  of  tbe  data  cell  section.  If  tbe  offset  were  from  tbe 
beginning  of  the  data  cell  section  then  tbe  RPointer  dereference  procedure  would  need  to  contain  an 
additional  addition  operation  to  account  for  the  sue  of  tbe  heap  header.  Since  this  sixe  b  a  function 
of  tbe  heap  index  sise,  which  b  not  constant  for  all  heaps,  the  dereference  procedure  would  have  to 
get  tbe  heap  index  length  from  the  beap,  adding  another  memory  reference  to  the  procedure. 
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Figure  3.6:  Heap  format 
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Figure  3.7:  Index  element  format 


The  tire  of  the  heap  index  is  fixed  at  the  time  a  heap  is  created.  An  alternative  approach  would  be 
to  allocate  the  index  within  the  data  cell  section  and  to  maintain  a  pointer  from  the  heap  header  to 
the  current  heap  index.  With  this  approach,  when  the  index  fills  up,  a  new  copy  could  be  allocated 
and  the  pointer  from  the  header  could  be  adjusted.  This  approach  is  slightly  more  complicated  and 
introduces  yet  another  layer  of  indirection  that  must  be  followed  at  LPointer  dereference  time.  For 
these  reasons,  the  current  OM  implementation  simply  uses  a  fixed  length  vector  in  the  heap  header. 
The  elements  of  the  vector  alternate  betveeo  RPo Inters  and  reference  counts  as  shown  in  figure  3.7. 


3.10  OM  Types:  More  details  i 

3.10.1  Getting  code  into  T 

Before  discussing  the  issue  of  user-defined  types  in  OM,  we  must  briefly  examine  the  environment 
in  which  we  expect  programmers  to  work.  We  are  not  attempting  to  build  a  single-language, 
integrated  program  editing,  debugging,  and  production-use  environment  like  Smalltalk.  (Such  on 
environment  would  be  nice  to  have,  but  is  outside  the  scope  of  this  work.)  Programmers  will  write 
their  programs  using  a  conventional  text  editor  and  have  another  context  consisting  of  a  T  interactive 
system  augmented  by  OM.  The  text  editor  may  be  embedded  within  the  same  process  ms  the  T 
system  or  may  be  in  a  separate  process  but  in  either  csss,  the  maintenance  of  the  programmer’s 
code  is  outside  the  scope  of  T  and  OM.  j 

T  source  code  in  text  files  must  be  compiled  before  it  can  be  incorporated  into  a  T  environment. 

By  ‘incorporation*  we  mean  a  process  that  makes  user  procedures  and  definitions  available  within 
a  T  environment. 

T  has  two  compilers:  the  utnitrd  compiler,  which  produces  tree-oriented  intermediate  code  that 

can  be  executed  by  an  interpreter  that  is  present  in  the  T  environment,  and  TC,  which  produces 

native  machine  instructions  (that  can  be  executed  by  the  real  processor).  TC  is  much  slower  than  I 

the  standard  compiler.  However,  the  compiled  code  produced  by  TC  executes  much  more  quickly 

than  the  compiled  code  produced  by  the  standard  compiler.  TC  produces  its  result  into  a  file 

(called  an  object  file)  of  machine  instructions  which  can  then  be  read  into  tbe  T  environment.  The 

standard  compiler  dispenses  with  the  object  file  and  produces  the  intermediater  code  directly  into 

tbe  T  environment.  It  is  not  possible  to  save  the  output  of  this  compiler*,  but  it  runs  so  fast  that  it  t 


‘Not*  the*  thieve  s  food  example  oi  a  rituatios  is  which  a  pec— sent  object  eyetetn  would  be  very  useful  -  the 
compiled  code  could  be  esved  as  s  penssacat  object 
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is  acceptable  to  have  the  programmer's  source  code  compiled  each  time  it  needs  to  be  incorporated 
into  a  T  environment.9 

The  T  interactive  environment  communicates  with  the  user  via  a  “read,  compile,  interpret,  print* 
loop  that  reads  a  T  source  string,  compiles  it  into  inlermidis.te  code,  Laterpretively  executes  the 
intermediate  code,  and  prints  the  results  and  then  repeals  the  cycle.  The  ‘compile,  interpret*  step 
is  sometimes  called  eoaiastioa  and  the  loop  is  called  the  ‘read,  evti,  print  loop*  (or  REPL  for  short). 

The  LOAD  procedure  takas  a  file  name  argument  and  inccry  orates  the  contents  of  the  file,  if  the  file 
is  an  object  file,  the  binary  loader  is  invoked.  Otherwise,  the  contents  of  the  file  is  incorporated  by 
applying  the  RSPL  to  the  file. 


3.10.2  User-defined  types 

User-defined  extend  types  are  created  using  the  DEEIXE- !  OBJECT-TYPE  special  form.  This  form 
defines  a  type  and  an  associated  set  of  methods  for  objects  of  that  type.  The  syntax  and  behavior 
of  EST  I.'IE- 1  C3JECT-TYPZ  is  related  to  T'»  OBJECT  form,  so  we  will  examine  the  latter  first. 

The  C3JECT  form  is  both  declarative  and  procedural.  It  declares  a  set  of  handled  operations  and 
associated  methods,  and  allocates  an  object  that  responds  to  the  declared  set  of  operations  in  the 
specified  way.  The  syntax  of  C3JECT  is: 

(OBJECT  call-part  Mthod-part) 

The  call-part  can  be  ignored  for  our  purposes.  The  aathod-part  is  a  list  of  method  clause.  The 
syntax  of  a  method  clause  is: 

(*nthod-haad  ■ethod-body) 

Where  a  Method-head  looks  like: 

(operation  arjl  . . .  argn) 

operation  is  an  expression  (typically  just  a  variable)  whose  value  is  an  operation.  The  axgi  are 
the  arguments  to  the  operation.  Within  the  aethod-body  -  the  code  that  implements  the  method 
-  the  argi  are  bound  to  the  values  in  the  operation  invocation.  The  first  argument  is  always  the 
object  to  which  the  operation  is  being  applied;  this  argument  is  called  the  «<J /  eryemcmt  If  the 
method  wants  to  apply  another  operation  to  the  object,  it  applies  the  operation  to  the  value  of  the 
self  argument. 

Execution  of  an  OBJECT  special  form  yields  (a  reference  to)  a  new  object.  The  new  object  is 
closed  over  the  lexical  environment  in  which  the  OBJECT  form  appear*.  Method  bodies  can  contain 
references  to  variables  that  are  lexically  apparent  from  but  defined  outside  the  OBJECT  form.  When 
a  bandied  operation  is  applied  to  the  result  of  the  OBJECT  special  form,  the  appropriate  method  is 
•elected  from  the  object’s  Method-part  and  is  executed;  references  to  closed-over  variables  in  the 
method  yield  the  values  those  variables  had  at  the  time  the  object  was  created. 

How  does  the  behavior  of  C3JECT  map  onto  our  model  of  objects  as  a  vector  of  slots  containing 
references  to  other  objects?  The  OBJECT  special  form  does  not  say  anything  about  slots.  Note 
however,  the  implementation  of  the  ‘closing  over*  procedure  requires  that  space  be  allocated  to 
hold  the  values  of  closed-over  variables  at  the  time  the  closure  is  created.  This  space,  plus  a 
reference  to  an  object  that  contains  the  methods,  w  the  object.  Thus,  the  closed-over  variables  see 
the  slots  in  the  object. 

Consider  the  following  piece  of  code:  ’  r 

*Moat  Liap  eyetersa  call  somethin*  like  the  standard  compiler  a  tmdtr,  and  somethin*  like  TC  a  tomfitr.  In  fact,  in 
T,  moat  isen  are  not  aware  that  there  ta  a  etandard  compiler  that  b  converting  their  rouree  code  into  intermediate 
code;  they  think  that  T  b  airapiy  Interpreting  their  aource  code. 
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(Dsraz  no 

(LAMBDA  (X  T  Z) 

(objzct  ra 

((OME-OF  SELF  X) 

(♦IX  T)) 

((ANOTHZX-OP  SELF  X) 

(CAB  Z))))) 

This  code  assigns  a  procedure  of  three  arguments  to  the  variable  FCO.  The  procedure  return*  an 
object  that  handles  two  operations  called  OM1-0P  and  AJtOTEZI-OP.  The  object  is  dosed  over  the 
variables  X,  T,  and  Z  which  are  the  arguments  to  the  procedure. 

Note  that  each  execution  of  the  OBJECT  form  yields  a  new,  distinct  object: 

(SET  A  (TOO  1  2  ‘(THIS  IS  A  LIST)) 

(SET  B  (TOO  10  20  * (ALPHA  BETA  GAMMA)) 

(OXE-OP  A  6)  ->  (♦  5  X  Y)  -»  (♦  S  1  2)  ->  8 
(ONE-OP  B  6)  “>  (*  6  X  Y)  ->  (♦  5  10  20)  ->  35 

The  representation  of  the  object  that  is  the  value  of  A  is  something  like: 

A - >  + - -+ 

I  • - i - >  Object  code  for  ONE-OP  and  AXOTHEJt-OP 


X:  1  * - 1 - >  1 

Y:|  1 - >2 

Z;  |  1 - >  (THIS  IS  A  LIST) 

♦— - - — —*■ 

The  traditional  term  (from  Smalltalk)  for  variables  that  are  available  to  the  method  clauses  is 
isstsaM  verisUes.  Instance  variables  are  the  names  of  the  slots  of  an  object.  The  values  of  instance 
variables  are  what  make  one  instance  of  an  object  created  by  the  OBJECT  special  form  different  from 
another  instance  of  an  object  created  bf  <A«  asm*  OBJECT  form. 

Smalltalk  and  Lisp  Machine  Lisp  [53]  support  object-oriented  programming  facilities  similar  .o  TV 
One  way  in  which  their  facilities  differ  from  IV  is  that  in  Smalltalk  and  LM  Lisp  there  are  separate 
primitives  for  declaring  types  of  object  and  creating  an  object  of  a  particular  type.  Also,  in  the 
declarative  form  the  instance  variables  are  dedared  explicitly  and  are  not  determined  by  the  context 
surrounding  the  declaration.  The  number  of  instance  variables  that  are  declared  determines  the  size 
of  objects. 

Taking  after  Smalltalk  and  LM  Lisp,  OM  has  a  declarative  mechanism  for  introducing  new  object 
types.  The  reason  we  adopted  this  approach  is  that  we  feel  that  it  is  required  in  a  permanent 
object  system.  The  goal  of  T’s  object-oriented  support  is  to  allow  object  types  to  be  unnamed  and 
implidtly  created;  T  object  type  definitions  are  dependent  on  context  (Le.  the  context  surrounding 
the  OBJECT  form).  Our  goals  are  different. 

As  a  programmer  debugs  procedures,  he  edits,  compiles,  aud  re-incorporates  all  or  parts  of  files. 
He  may  destroy  his  T  process  and  start  a  new  one  and  incorporate  his  procedures  into  it.  In  T, 
the  incoi poration  (not  the  execution)  of  a  procedure  that  contains  an  OBJECT  form  constitutes  the 
definition  of  a  new  type.  We  do  not  believe  that  this  is  the  appropriate  way  to  introduce  new  types 
into  a  permanent  object  system. 

Creating  a  type  in  a  permanent  bject  system  is  a  serious  thing:  the  system  is  obliged  to  retain  all 
the  information  related  to  the  type  for  as  long  as  objects  of  that  type  exist.  In  our  system,  since  we 
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can  net  store  object  code  ia  heaps,  this  retention  means  the  writing  of  an  external  file  that  describes 
the  type  (more  oa  this  later).  Thu*,  it  seems  undesirable  that  types  are  created  essieatlally  as  a 
side-eifoct  like  ia  T. 

It  must  be  possible  to  modify  the  methods  that  make  up  a  type.  TL’s  means  it  must  be  possible 
to  refer  to  a  type  -  that  the  type  have  a  name.  Ia  T,  it  is  not  possible  .  >  incorporate  a  revidon  of 
an  cxbtiuj  CdJdCT  form.  Ia  fact,  there  is  no  way  to  refer  to  aa  existing  ;JhCT  Hewn  it  is  honed 
vl.'hia  aa  opaque  compiled  object.  In  OM,  types  have  text  names  and  a  programmer  can  get  all 
the  Lifonnntica  about  type  simply  by  knowing  the  type’s  name. 

The  essence  of  the  problem  of  user-defined  types  ia  our  system  is  that  code  tiu  implements  types 
must  be  treated  dlifereatly  from  ordinary  user  code.  CM  need  not  and  does  not  kc< .  track  of  all  user 
procedures  that  are  incorporated  into  a  running  T/OM  environment.  But  OM  rats...  keep  track  of 
code  and  oth-e'  information  tuat  applies  to  type  definitions,  regardless  of  whether  tho^r  definitions 
apply  to  types  that  are  being  used  in  any  active  T/OM  environment. 

DEfTiE-  1 G3 J2CT-TTPS  is  the  OM  special  form  for  introducing  new  types.  The  syntax  of  „  "'flSE- 
1 OBJECT-TYPE  Lsi 

(BEJllJE- 1 C2  J2CT-7TP2  type-nans 
options 

last  ancs—varlabls* 
authod~clsc.se  a) 

type-naae  is  the  name  of  the  sew  type,  uptioas  is  a  list  containing  certain  options  about  whether 
the  instance  variables  are  accessible  outside  the  Mthod-claosws.  iartaacs—v&riablas  are  the 
names  of  the  slots  of  the  object.  Ms&oi-claosM  is  similar  to  the  method  clauses  of  C3J2CT. 

Operations  applicable  to  OM  objects  are  created  using  !  E2FI5JS-C?E3UTID1I  which  is  analogous  to 
DSFIKE-CPmTTOll. 

All  information  about  OM  types  is  scored  in  a  special  heap  called  the  type  Are?.  CM  has  special 
knowledge  about  this  heap  ia  much  the  same  way  that  it  does  shout  the  E1D  heap  discussed  earlier. 
The  type  heap  contains  several  thing*: 

•  The  next  type  ID  to  assign. 

•  A  table  translat’ng  type  names  to  type  IDs. 

•  A  table  translating  type  IDs  into  type  names. 

•  A  table  translating  type  IDs  into  type  source  file  names. 

•  A  table  translating  type  IDs  into  lengths. 

We  will  explain  how  this  information  is  maintained  by  explaining  the  behavior  of  EEFIM2- 1C3JECT- 
TYPE.  The  execution  of  a  DZPI32- 1C3J2C7-TYPE  form  causes  a  new  OM  object  type  to  be  created.  A 
new  type  ID  is  generated  by  reference  to  the  type  heap.  A  slightly  modified  version  of  the  DEFISJE- 
I  OBJECT-TYPE  form  b  written  to  a  new  file  (called  a  fyys  sovtrs  file)  whose  name  b  entered  into 
the  table  translating  type  IDs  into  type  source  file  names  is  the  type  heap.  This  file  b  owned  by 
the  OM  system,  not  the  uses  The  name  and  ID  of  the  type  b  entered  into  the  type-name-to-type 
ID  translation  table  and  the  type- ID- to- type- acme  translation  table.  The  type  ID  and  type  length 
(number  of  slots)  b  entered  into  the  typo-lD-to-'ength  translation  table. 

When  the  DE7I82- !  OBJECT-TYPE  form  b  compiled,  the  method  clauses  are  not  compiled*  When  the 
result  of  compiling  the  DE7ISE- 1  OBJECT-TYPE  form  b  executed,  it  b  manipulating  method  clause 
source  code,  sot  object  code.  Thus,  incorporating  a  source  file  containing  a  CEFIME-)  OBJECT-TYPE 
form  does  not  result  in  the  compilation  of  method  clauses.  This  aspect  of  OM  types  will  become 
dearer  as  we  describe  operation  dbpalch  in  OM. 
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3.10.3  OM  operation  dispatch 

Operation  dispatch  is  the  process  of  invoking  an  object’s  method  in  response  to  an  operation  being 
applied  to  the  object.  In  CM,  operation  dispatch  happens  when  an  OM  operation  is  applied  to  an 
OM  object.  The  operation  invocation  is  syntactically  identical  to  a  procedure  call,  except  that  the 
head  of  the  form  must  evaluate  to  an  operation  object  instead  of  a  procedure  object.  The  first  two 
arguments  to  the  operation  must  specify  the  object  to  which  the  operation  is  to  be  applied.  These 
two  arguments  must  be  m  RPointer  and  an  RHeap. 

Operation  dispatch  begins  by  extracting  the  type  ID  from  the  first  slot  of  the  object  to  which 
the  operation  is  being  applied.  This  type  ID  is  looked  up  in  a  per-process  table  (residing  in  the 
transient  heap)  that  translates  type  IDs  into  active  type*.  An  active  type  is  one  whose  handler 
has  been  incorporated  into  the  transient  heap.  If  the  type  ID  b  found  in  the  table,  the  associated 
handler  b  Invoked.  The  handler  b  simply  a  procedure  that  compares  the  operation  object  being 
invoked  against  all  the  operation  objects  listed  in  the  the  DEFINE- 1 OBJECT-TYPE  for  the  type  ID.  If 
the  operation  b  handled  by  tbe  type,  the  associated  method  b  invoked.  Otherwise,  if  the  operation 
has  a  default  method,  it  b  applied.  Otherwise,  an  error  b  raised  since  the  operation  can  not  be 
handled. 

If  the  type  ID  b  not  found  in  the  per-process  active  type  table,  the  operation  dbpatch  meJi&nbm 
translates  the  type  ID  into  a  type  source  file  name  by  referring  to  the  type  heap.  The  type  source 
file  b  then  compiled  by  the  standard  compiler,  incorporated  into  the  T/OM  environment  and  a 
handler  b  constructed.  If  a  version  of  the  type  source  file  that  has  been  compiled  by  TC  exists,  that 
compiled  version  will  be  incorporated  instead  of  invoking  the  standard  compiler.  The  type  ID  and 
handler  are  entered  into  the  active  type  table  and  operation  dbpatch  proceeds  as  described  above. 

3.10.4  Type  redefinition 

In  any  permanent  object  system,  suppose  a  programmer  has  defined  a  type  and  then  creates  some 
objects  of  that  type.  Now  suppose  that  the  programmer  want*  to  modify  the  type.  Does  he  w-nt 
to  modify  the  behavior  of  existing  objects  of  that  type  or  does  he  want  only  objects  created  after 
the  change  to  have  their  behavior  based  on  tbe  modified  type  and  to  have  old  objects  retain  their 
old  behavior?  If  the  former,  what  sorts  of  changes  to  a  type  are  compatible  with  existing  objects? 
If  the  latter,  in  what  sense,  if  any,  are  tbe  unchanged  and  changed  types  the  same  type? 

There  are  cases  where  type  definitions  need  to  be  modified  without  creating  a  new  type.  Fixing 
bugs  b  one  example;  if  a  change  to  a  type  definition  b  the  fixing  of  a  bug  in  the  definition,  old 
objects  will  probably  want  their  behavior  modified  to  the  new,  less  buggy  behavior. 

There  are  cases  where  the  changing  of  a  type  definition  must  be  treated  carefully.  For  example, 
suppose  the  new  definition  specifies  a  larger  number  of  instance  variables.  If  the  new  definition  b 
applied  to  old  objects,  an  error  will  occur  when  the  siot  that  doesn’t  exist  in  old  objects  b  referenced. 
One  might  be  tempted  to  say  that  the  sew  definition  with  a  larger  number  of  instance  variables  b 
creating  a  new  type.  Thb  attitude  b  not  entirely  adequate  though.  Tbe  old  type  and  new  type 
might  have  much  in  common.  By  forcing  them  to  be  different  types,  we  are  causing  whatever 
similarity  the  two  types  have  to  be  lost.  For  example,  methods  in  the  new  type  that  don’t  refer  to 
the  new  instance  variables  might  be  identical  to  methods  in  the  old  type.  If  a  bug  b  found  in  such 
a  method,  the  fix  should  be  applied  to  both  the  old  and  new  type. 

Conventional  databases  have  had  to  deal  with  problems  similar  to  those  described  above.  The 
traditional  solution  b  to  force  tbe  user  to  dump  his  data  and  then  reload  it  using  the  new  type 
(schema).  Thb  b  essentially  a  result  of  the  fact  that  database  systems  typically  use  highly  compact 
and  optimised  data  structures  to  represent  data.  Such  representations  are  not  easy  to  change 
dynamically. 

We  do  not  yet  know  how  to  solve  tbe  problem  of  type  redefinition.  The  Smalltalk  and  LM  Lbp  object 
type  systems  essentially  do  not  deal  with  the  problem  in  full  generality.  The  underlying  structure 
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of  our  system  allows  both  existing  types  to  be  modified  and  new  types  to  be  created.  Presently 
D2?I11E-!03J2CT-TY?Z  always  creates  a  new  type  (i.e.  type  ID).  Once  created,  an  object’s  behavior 
is  not  changed  by  subsequent  executions  of  E27U1Z-  IC3J2CT-TTPE.  However,  since  this  form  specifies 
the  type  name,  it  would  be  trivial  to  make  it  optionally  modify  the  behavior  of  an  existing  type  ID 
to  which  the  type  name  translates.  All  that  is  required  is  that  instead  of  adding  an  entry  to  the 
tables  in  the  type  heap  that  take  a  type  ID  as  a  key,  that  those  tables  be  updated  to  missel  the  tew 
duum  non. 

To  deal  with  the  caw  where  a  new  type  needs  to  be  generated  (e.g.  when  the  number  of  instance 
variables  has  changed)  we  would  like  to  consider  the  new  type  to  be  a  new  jesersihcn  of  an  existing 
type.  For  some  purposes  different  generations  of  the  same  type  will  be  considered  different  types, 
but  for  other  purposes  they  might  be  considered  die  same  type.  For  example,  the  two  types  would 
be  considered  different  by  the  operation  dispatch  mechanism.  However,  if  an  object  type  definition 
editor  were  V  be  included  as  part  of  T/OM,  the  two  types  might  be  considered  to  be  same  for  the 
purpose  of  raethod  modification. 


Chapter  4 


Programmer  interface 


The  previous  chapter  dealt  with  the  low-level  implementation  issues  in  OM.  We  now  address  the 
issues  related  to  how  programmers  actually  use  OM.  The  major  topics  of  this  section  are  the  syntactic 
tools  the  programmer  uses  and  semantic  issues  the  programmer  mast  deal  with.  At  the  end  of  this 
chapter  we  describe  two  sample  uses  of  OM. 


4.1  Simple  syntactic  tools 

T,  like  most  Lisps,  has  a  mechanism  for  modifying  the  syntax  of  the  language.  This  mechanism  >s 
called  a  suers.  OM  defines  some  macros  to  make  programming  using  OM  more  convenient  and  less 
prone  to  error. 

VITH-ACTIVI-HEAP  is  a  macro  that  controls  heap  activation.  The  underlying  activation  control 
primitives,  ACTIVATE-HEAP  and  DEACTIYATE-HEA?  are  inconvenient  and  if  not  used  correctly  can 
lead  to  heaps  not  being  properly  deactivated.  For  example,  in: 

(DETIX2  (TOO  I  ID) 

(LET  ((HEAP  (ACTIVATE-HEAP  IE/))) 

(DEACTIVATE  aZAP  BID))) 

if  an  error  occurs  within  the  *...*,  and  the  stack  is  unwound  to  top-level,  DEACTIVATE- HEAP  will  uot 
be  called,  and  the  heap  will  be  left  active.  To  avoid  this  potential  problem,  the  procedure  should 
be  written: 

(DEPUTE  (POO  HID) 

(UHVIXO-PHOTECT 

(LET  ((HEAP  (ACTIVATE- HEAP  HID))) 

) 

( DEACTIVATE- HEAP  HID))) 

UHVIXO-PKOTXCT  is  a  T  special  form  that  insum  that  its  second  form  (the  call  to  DEACTIVATE- HEAP 
in  this  case)  will  be  executed. 

By  using  V  ITS ‘■ACTIVE -HEAP,  the  above  can  be  simplified  to: 

(DEPIME  (POO  HID)  '  r 

(WITH- ACTIVE -HEAP  HEAT  HID 
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Which  expand  into  a  definition  which  is  identical  to  the  V9YIJD-PE0TECT  version  above. 

MfTTH-LPOISTEX  is  a  more  sophisticated  macro  that  controls  the  activa^on  of  heaps  based  on 
LPointers.  Recall  that  objects  referred  to  by  LPointers  can  not  he  examined  until  the  LPointer 
is  converted  to  an  P-Pc inter/ RHaap  that  refers  to  an  object  in  an  active  heap.  IWIT2-LP0IHTES 
simplifies  tin:  writing  of  code  that  does  the  conversion.  For  example,  consider  a  procedure  that  takes 

an  R Pointer/ RHcap  to  an  LPointer: 

Ch::Ri:?2  (?co  l?  u-esa?) 

(•ifrn-LPcijim  (0/ 1?  u-esa?)) 

dPAia-caa  via  via))) 

The  first  part  (called  the  tfxcification)  of  the  !VXT3-L?CI5rrE2  form  specifies  the  LPointers  that 
will  be  used  within  the  second  part  (called  the  kWy)  of  the  1  VTT2-LP0I3T2&  form.  The  LPointer 
'.purification  is  a  lint  of  triples  (the  example  above  has  only  one  triple).  The  first  element  of  the 
triple  is  a  pseudo- van  able  that  will  be  described  shortly.  The  second  and  third  elements  of  the  triple 
are  a  reference  (RPointer/RHeap)  to  the  LPointer  being  tired. 

Ju.it  before  the  body  of  the  IVrn-LPCIinSt  is  executed,  all  the  heaps  named  by  the  LPointers  in 
the  specification  are  activated.  After  the  body  is  executed,  ail  these  heaps  are  deactivated.  (The 
macro  uses  ACTTVATE-B2A?  and  ESACTIYATE-ESAP  so  dynamically  nested  !  ¥lT3-L?OI3TfZS»  actually 
simply  manipulate  the  heap  motivation  count.) 

The  paeudo-variafcka  are  used  to  refer  to  the  RPointer/F.He&p  pairs  that  remit  from  converting  the 
LPointer  reference  into  a  reference  to  an  active  object.  Within  the  body  of  the  IflTB-LPCHTTSa, 
two  variables  are  introduced;  one  is  bound  to  an  RPoiater  that  refers  to  the  object  referred  to  by 
the  LPointer  and  the  other  is  bound  to  the  REeap  that  r.  ults  from  activating  the  heap  referred  to 
by  the  LPointer.  The  names  jf  these  variable  are  constructed  from  the  name  of  the  pseudo-variable. 
For  pseudo-variable  var,  the  variable  txsrlX  can  be  used  to  refer  to  the  RPoiater,  and  the  variable 
tmr!  3  can  be  used  to  refer  to  the  PJfeap. 

Also,  every  occurence  of  the  pseudo-variable  itself  is  replaced  by  two  variables  that  are  bound  to  the 
RPointer/RHeap  that  refers  to  the  object  referred  to  by  the  original  LPointer.  Thus,  the  example 
above  could  be  rewritten: 

(DErijn  (roo  l?  l?-hea?) 

(ivrni-Lrciijrm  ((v  l?  l?-ea?)) 

( IPAIX-CDX  Y))) 


4.2  Programming  with  two  kinds  of  references 

The  previous  chapter  described  the  primitives  for  derefencing  RPointer  and  LPointers.  However,  it 
did  not  address  the  question  of  how  a  program  is  to  know  which  derefesence  mechanism  «hould  be 
applied  to  a  particular  reference.  Should  the  decisiou  about  bow  the  reference  should  be  derefenced 
be  made  dynamically  or  statically?  For  example,  given  the  expression: 

(IPAIR-CAX  X  H) 

should  IPAIR-CAX  (statically)  assume  that  R/S  refers  to  an  OM  pair,  or  should  it  (dynamically)  see 
if  X/H  refers  to  an  LPointer  that  needs  to  be  dereferenced  to  reach  tbe  pair? 

Another  issue  related  to  having  two  kinds  of  references  is  tbe  kind  of  reference  returned  as  tbe  value 
of  a  procedure.  Given  the  nature  of  our  Implementation  environment,  a  procedure  always  actually 
returns  an  RPointer.  But  it  it  an  RPointer  to  the  object  being  returned,  or  is  it  an  RPointer  to  an 
LPointer  to  tbe  objoct  being  returned? 
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4.2.1  The  dynamic  approach 

The  dynamic  approach  requires  that  the  primitive  that  extracts  an  RPointer  from  an  object  look 
at  the  type  of  the  RPointer.  If  the  type  tag  indicates  that  the  type  is  LPointer,  the  primitive  could 
then  invoke  the  dereference  mechanism  on  the  LPointer.  Accessors  that  retrieve  a  slot  in  en  object 
have  to  check  to  see  if  the  type  of  thesr  argument  is  LPointer.  Recall  that  all  such  accessors  call 
HPOZHTSE-EXAXIJJE  to  get  the  contents  of  a  slot.  We  could  rewrite  Z?VZrK£-£ZXXUZ  to  be: 

(CE7ZMS  (RPCIXTOt-DUOUHI  HP  HEAP  I) 

(COMB  (CLFCIsmOt?  HP) 

(lWITH-LPOZmX  ({?  HP  HEAP))  ;•••  Dsrsf.  LPointer 

(apoims-EXAJons  pin  pih  i))) 

<t 

(sbeap-examzhi  hzap  (♦  i  (HPoima-CADoaiss  ip)))))) 

This  generality  comes  only  at  the  price  of  increasing  the  cost  of  the  dereference  mechanism:  every 
time  an  RPointer  is  extracted  from  an  object,  the  RPointer  must  be  examined  to  see  if  it  refers  to 
an  LPointer.1 

The  dynamic  approach  rlso  requires  that  accessors  that  modify  a  slot  in  an  object  have  to  check  to 
see  if  the  reference  being  stored  is  to  an  object  in  another  heap.  We  could  rewrite  EPOXMTEX-DEPOSIT 
(the  procedure  used  by  all  accessors  that  modify  slots  in  objects)  to  be: 

(cepzhe  (hpozkteh-deposzt  i?i  heapi  i  hps  heaps) 

(COOT  (OIQT  (-  HEAPI  HEAPS)) 

(HPOIXTEl-DEPCSIT 
t?l  HEAPI 
I 

(IECPCST-RPCIHTEX  IPS  HEAPS  HEAPI)  HEAPI)) 

(T 

(HHEAP-DEPCSrr  HEAPI  (♦  I  (HPOZHTEa-CABOHESS  HP))  OBJ))))) 

In  addition  to  the  cost  in  time,  there  is  a  cost  due  to  increased  code  rise.  HPOZHTEH-EXAMIHE  is 
expanded  in  line.  The  addition  of  the  LP0ZHTE2?  test  will  increase  the  aise  of  the  expansion.  To 
save  space,  the  code  to  dereference  the  LPointer  can  be  left  out  of  the  is  line  expansion;  only  the 
lent  and  a  call  tc  a  procedure  to  do  the  LPointer  dereference  will  be  included.  (In  the  case  where 
the  RPointer  points  to  an  LPointer,  the  cost  of  an  extra  procedure  call  is  not  significant  since  the 
LPointer  dereference  is  expensive  anyway.)  However  even  with  the  LPointer  dereference  moved  to 
a  subroutine,  me  sixe  of  the  compiled  HPOZHTXH-ECAMZHZ  will  increase  by  about  1/3  (recall  from 
section  3.5.2  that  the  original  sequence  is  about  3  instructions;  the  LPointer  test  and  subroutine 
call  will  be  at  least  3  instructions).  The  sixe  of  the  expanded  HPOZHTIH-DEPOSZT  will  increase  also. 

Besides  the  time  and  space  efficiency  problems  with  the  dynamic  approach,  there  is  a  logical  problem: 
the  RPointer  returned  after  automatically  dereferencing  an  LPointer  (in  HPOINTEH-EXAMZNE)  will 
be  to  an  object  in  heap  different  from  the  object  from  which  contained  the  RPointer  to  the  LPointer. 
The  returned  RPointer  is  useless  to  the  procedure  that  called  the  sccesso'  since  the  procedure  does 
net  have  a  handle  on  the  heap  that  contains  the  object  the  returned  RPointer  refers  to.  One  obvious 
way  to  get  around  this  problem  b  to  make  HPOZHTEH-EXAMKE  return  an  LPointer  in  case  it  has 
dynamically  dereferenced  an  LPointer 

(DE7ZHE  (HPGZXTEX-EXAMZIE  HP  HAP  I) 

(COHO  ((LPOZKTXi?  HP)  •  » 

( I WZTP-LPOZHTH  C CP  HP  HEAPS)) 


‘If  we  had  Mm  option  o i  buUdlnj  hardware  we  woo  id  trfue  that  this  M  could  be  performed  In  parallel  with  the 
uxxr- EZiMHE;  but  we're  sot  to  we  won't. 
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Figure  4.1:  An  LPointer  to  two  pairs 


OEXPO-TT-XPOIXTEa  (RPOIUTZl-EUKINE  PI  I)  HEAP))) 

(T 

(RHIAP-EXAMIN2  E2A?  (♦  1  (R?CISTE?.-CADDR2SS  I?)))))) 

However,  this  solution  is  unsatisfactory.  Assume  ?  1 2/P !  3  refers  to  an  LPoLnter  in  heap  A  that  refers 
to  a  pair  in  heap  B  and  assume  that  the  ear  of  that  pair  is  also  a  pair.  Figure  4.1  shows  how  the 
pairs  are  arranged.  To  retrieve  the  edr  of  the  second  pair,  using  the  dynamic  approach,  we  could 
write: 

(LET  ((X  (1PAIR-CER  (IPAIS-CAS  P!R  P1H)  FIE)}) 

...) 

Since  PIR/PiH  refers  to  an  LPointer,  the  LPointer  will  be  dynamically  dereferenced  by  I  PAIR- CAR. 
The  value  returned  by  I  PAIR-CAR  will  be  a  newly  allocated  LPointer  (in  heap  A)  to  the  object 
referred  to  from  the  car  of  the  first  pair.  When  IPAIR-COR  is  applied  to  the  LPointer  returned  by 
I  PAIR -CAR,  the  LPointer  will  be  dynamically  dereferenced. 

Simply  to  follow  this  ctr-cdr  chain,  we  allocated  a  LPointer  and  did  an  LPointer  dereference.  The 
LPointer  becomes  garbage  as  soon  as  the  1PAI3-C3R  is  executed. 


4.2.2  The  static  approach 

Instead  of  automatically  dereferencing  and  creating  LPointers,  we  can  leave  it  up  to  the  programmer 
to  specify  where  LPointers  are  and  where  LPointers  need  to  he  created  as  pari  of  the  programming 
process  (i.e.  statically).  The  static  approach  is  predicated  on  the  fact  that  the  structure  of  an 
application’s  objects  -  i.e.  which  objects  are  in  which  heaps  and  where  the  inter-heap  references  are 
-  is  fixed.  OM  is  a  system  designed  to  deal  with  applications  whose  data  structures  are  fixed  in  this 
way. 

To  use  the  6tatic  approach,  the  programmer  must  adopt  a  certain  style  of  programming.  The  goal 
of  the  style  is  to  minimize  (and  hopefully  reduce  to  zero)  the  amount  of  storage  (especially  garbage) 
that  is  allocated  by  procedures  that  do  not  create  logically  new  objects.  ITiat  is,  we  don’t  want 
procedures  to  allocate  storage  simply  to  return  results  that  in  principle  do  not  require  storage  to  be 
allocated.  In  particular,  we  want  to  avoid  allocating  LPointers  when  it  is  not  necessary  to  do  so. 

If  the  structure  of  an  application’s  data  is  fixed,  the  need  for  the  generality  of  the  dynamic  approach 
is  reduced.  For  example,  it  is  not  necessary  for  accessors  to  dynamically  check  to  see  if  a  reference 
is  through  an  LPointer  if  it  is  possible  to  statically  assert  that  the  reference  is  never  through  an 
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LPointer.  In  cue  the  programmer  can’t  assume  where  the  LPointen  are,  he  can  insert  the  check 
for  LPointen  himself  (or  simply  introduce  a  layer  of  procedures  that  do  the  check  and  dispatch 
accordingly).  In  this  case,  the  system  is  no  more  or  Ism  efficient  than  the  dynamic  approach.  In  all 
other  eases  however,  the  dereference  mechanism  is  cheaper. 

Another  aspect  of  the  static  approach  is  that  LPointen  are  explicitly  created.  Note  however  that 
LPointen  will  not  need  to  be  created  in  all  the  cases  in  which  the  dynamic  approach  would  have 
created  them.  For  example,  using  the  static  approach,  following  the  atr-cdr  chain  described  above 
would  be  written  as: 


(  MTITH-LPOINTEX  ((Q  PIR  P1H)) 

(LET  ((X  (1PAIR-CDR  (IPAIR-CAR  Q 1  ft  QtS)  Q!B)}) 

...)) 


Note  that  we  are  assuming  the  original  RPOINTER-EXRXIME  -  the  one  that  does  not  automatically 
dereference  and  create  LPointen. 

Within  the  body  of  the  INITH -LPOINTER,  Q 1  ft/Q  1 H  refen  to  the  first  pair  in  heap  B.  The  IPAIR-CAR 
returns  an  RPointer  to  the  object  referenced  by  the  first  pair’s  car  -  the  second  pair  in  heap  B.  The 
IPAIR-CDR  returns  an  RPointer  to  the  object  referenced  by  the  second  pair’s  eir.  Note  that  we  can 
use  QIR  as  the  second  argument  to  IPAIR-CDR  because  we  know  that  the  second  pair  is  in  the  same 
heap  as  the  first  pair  (which  is  identified  by  Q I  ft/Q  18). 

Unlike  in  the  dynamic  approach,  the  above  expression  does  not  cause  a  gratuitous  LPointer  to 
be  created  and  then  dereferenced.  The  general  case  of  which  the  expression  is  an  example  is  the 
successive  application  of  procedures  to  an  object: 


(PI  CF2  ...  (Fn  PIR  P1H)  ...  PIE)  PIE) 

where  PtR/PIH  is  a  reference  to  an  LPointer  and  the  return  values  of  the  Fi  are  objects  in  the  same 
heap  as  the  object  referred  to  by  that  LPointer.  In  the  dynamic  approach,  since  PIR/PtB  refers  to 
an  LPointer,  an  LPointer  will  be  allocated  for  each  intermediate  object,  and  this  LPointer  will  be 
dereferenced  right  away  by  the  next  procedure  application.  The  static  approach  avoids  this  cost  by 
making  the  programmer  explicitly  specify  (via  I NTTB-LPOINTER)  that  a  piece  of  code  should  run 
"within  a  particular  heap”  and  that  intermediate  results  should  not  have  an  LPointer  allocated  to 
refer  to  them. 

In  the  static  approach,  since  LPointers  are  never  automatically  allocated,  it  is  also  up  to  the  pro* 
grammer  to  explicitly  specify  calls  to  I EXPORT-RPOIHTEE.  Which  procedures  allocate  and  return 
LPointers  is  a  convention  determined  and  followed  by  the  programmer.  His  procedures  fall  into  one 
of  two  classes:  those  that  work  within  a  single  heap  and  return  RPointers  to  their  results,  and  those 
that  span  heaps  (by  dereferencing  LPointers)  and  return  LPointers  to  their  results.  Procedures  in 
the  latter  class  will  have  the  form: 

(DEFINE  (0  QIR  Q1B) 

(  ! WITH -LPOINTER  ((P  QIR  (JIB)) 

(IEXP0RT-RP0INTER  (FI  (F2  ...  (Fn  FIR  FIB)  ...  PIB)  FIB) 

PIH 

QIH)}) 


Procedures  like  C  take  an  LPointer  to  some  object,  dereference  the  LPointer,  apply  a  set  of  procedures 
to  objects  within  the  same  heap  as  the  object  referred  to  by  the  LPointer,  and  then  return  an 
LPointer  (in  the  same  heap  as  the  original  LPointer)  to  the  return  value  of  0. 
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4.3  A  pre-processor 

Tbs  fact  that  an  OM  procedure  that  takas  a  reference  to  an  OM  object  take*  two  arguments  to  pass 
the  reference  is  a  nuisance  to  the  programmer,  The  two  argument*  logically  identify  a  single  object. 
Normally  a  programmer  mas  one  argument  to  identify  a  single  object. 

The  pre-processing  approach  takes  advantage  of  the  fact  that  there  is  a  great  degree  of  regularity 
in  the  way  RPointen  and  Elleaps  are  passed  among  procedures.  Note  that  all  OM  procedures  that 
take  an  RPointer  and  RHeap  return  an  RPointer  that  refers  to  an  object  that  is  the  same  heap 
as  the  RPointer  argument.  With  some  small  syntactic  modifications  to  T,  the  programmer  esn 
be  relieved  of  the  chore  of  specifying  both  the  RPointer  and  REeap  argument.  A  pre-processor 
can  automatically  turn  the  programmer’s  one  argument  version  of  the  code  into  the  two  argument 
version  that  the  OM  primitives  expect. 

The  basic  idea  of  the  syntactic  modification  is  that  the  programmer  will  declare  all  variables  that 
hold  a  reference  to  an  OM  object.  For  example; 

(ESTIMS  (P  (CliVMt  A)  B  (Cm2  C)) 

(IF  (2?) 

(♦  (Q  A)  B) 

C» 

This  defines  a  procedure  P  that  takes  three  arguments,  the  first  and  last  of  which  are  references  to 
OM  objects.  A  pre-processor  takes  the  definition  and  transforms  it  into  the  two-argument  style; 

(C2?IHS  (?  AIR  A1S  B  C1R  CIS) 

(IF  (27) 

(♦  (q  AIR  A!)  B) 

CIS)) 

ear!  K  and  ear  1 S  are  substituted  for  all  occurences  of  wr.  However,  if  ear  appears  in  return  position, 
just  vsrlR  is  substituted  for  ear. 

The  pre-processor  is  not  general  yet.  The  transformation  above  relies  on  the  fact  that  Q  returns 
an  integer,  not  an  OM  object,  and  that  the  result  of  Q  is  being  passed  to  a  procedure  that  takes 
integers,  not  OM  objects.  What  if  Q  returned  an  OM  object  (i.e.  an  RPointer)  and  instead  of  ♦ 
receiving  the  result,  the  procedure  being  called  expects  an  OM  object  as  its  first  argument?  That 
is: 

(D2FINZ  (?  (ONVaR  A)  B  (CMVAJt  C)) 

(IF  (2?)  _  ' 

(R  (Q  A)  B) 

«) 

(D2FIM  (R  (OMVAR  X)  T) 

(IF  T 
X 

r)) 

Note  that  R  is  really  a  procedure  of  three  arguments:  the  X  argument  get*  expanded  into  two 
arguments  by  the  pre-processor.  Thus,  when  P  calls  R  it  needs  to  supply  the  RHe&p  argument  that 
goes  with  the  RPointer  returned  by  Q. 

In  general,  a  call  form  A  that: 

1.  Invokes  a  procedure  that  returns  an  RPointer,  and  •  * 

2.  Appears  in  the  argument  position  of  some  other  call  form  B  that  takes  an  OM  object  in  that 
position, 

must  have  an  RHeap  inserted  after  call  form  A: 
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(K  ...  «  ...)  *  ...) 

*  mm  m 


♦--- — - B - — - — ♦ 

The  •  marks  the  point  of  insertion. 

For  the  pre-processor  to  do  this  insertion,  it  must  know  something  about  the  procedure  being 
invoked.  In  particular,  for  a  procedure  Q,  it  must  know  the  RHeap  that  is  to  be  associated  with 
the  RPointer  that  Q  returns.  Fortunately,  this  is  generally  a  static  property  of  the  procedure.  The 
RHeap  of  the  returned  RPointer  is  the  same  as  the  RHeap  of  one  of  the  objects  passed  to  the 
procedure.  Thus,  we  can  augment  the  definition  of  Q  with  a  declaration  of  what  argument’s  RHeap 
is  the  RHeap  of  the  returned  RPointer 

(DEFINE  (Q  (OWVAR  M))  (KETURN-KHIAP  K) 

) 

This  says  that  Q  returns  an  OM  object  identified  by  the  RPointer  returned  by  Q  Mid  the  RHeap 
associated  with  Q’s  first  argument,  X.  This  is  enough  information  so  that  the  pre-processor  can 
transform  the  definition  of  P  into: 

(DEFINE  (P  Al*  All  B  Cl*  CIH) 

(IF  (27) 

(*  (Q  AIK  AIH)  All  B) 

Cl*)) 

The  A I RHEAP  in  the  call  to  *  is  inserted  based  on  the  fact  that  the  definition  of  Q  says  that  the 
RHeap  of  the  result  of  Q  is  the  same  as  the  RHeap  of  Q’s  first  argument. 

If  the  RETURN-RHEA?  clause  is  omitted,  the  pre-processor  assumes  that  the  procedure  returns  a 
non-OM  object  (e.g.  an  integer). 

While  it  appears  that  the  pre-processor  can  automatically  generate  RHeap  arguments  for  many 
cases,  the  programmer  is  still  responsible  for  knowing  when  a  data  structure  crosses  a  heap  bound¬ 
ary.  Doesn’t  the  programmer  have  to  mention  an  RHeap  explicitly  at  this  point?  The  answer 
is  “no"  because  of  the  pre-processor  in  combination  with  the  I WITH -LPO INTER  macro  enables  the 
programmer  to  forget  about  the  RHeap  argument  even  in  this  case. 

Consider  the  following  simple  example  of  a  procedure  that  deals  with  data  in  multiple  heaps.  Sup¬ 
pose  a  procedure  P  is  passed  a  list  of  LPointers.  Each  LPointer  is  a  reference  to  a  vector  of  integers 
in  another  heap.  Suppose  we  want  ?  to  sum  up  all  the  integers  in  all  the  heap.  We  could  write  P  as 
follows: 

(DEFINE  (P  (OMVAK  L)) 

(COND  (( I  NULL?  L) 

0) 

(ELSE 

(♦  ( IWITH-LPOINTE*  ((VEC  (IPAIS-CA*  L))) 

(LOOP  (INITIAL  (SUM  0)) 

(INC*  I  FROM  0  TO  (-  (I VECTOR -LENGTH  VEC)  l)j 
(DO  (SET  SUM  (+  SUM  (! VECTOR- ELT  YEC  I)))) 

(RESULT  SUM))) 

(P  (1PAIR-CDR  L)))))) 
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Note; 

I  HULL?  is  a  primitive  procedure  that  takes  an  RPointer/RHeap  and  returns  tree  if  the  RPointer  is 
to  the  null  object. 

IPAI&-CE2  is  a  primitive  procedure  that  takes  an  RPointer/RHeap  to  as  OM  pair  aad  returns  the 
cdr  of  the  pair.  IPAIS-CU2  La  declared  to  the  pro- processor  to  return  an  RPointer  that  is 
in  the  same  heap  au  the  argument  to  1PAI2-CCIL  Thus,  in  the  recursive  call  to  P  inside  the 
definition  of  P,  the  RHeap  associated  with  L  (i.e.  the  second  real  argument  to  P)  will  be 
inserted  after  the  call  to  1?AI2-GDL 

l\££T3?.~LDi!GTH  is  a  primitive  procedure  that  takes  an  RPointer/RHaap  to  an  OM  vector  aad 
returns  -,o  integer. 

1VZC7031-EL?  is  a  primitive  procedure  that  taka  an  RPointer/RBtap  to  an  OM  vector  and  an 
integer  onset  into  the  vector,  and  returns  the  RPointer  at  the  I’pedSed  offset.  IVSCTOt-ELT 
is  declared  to  the  pre-processor  to  return  an  RPointer  that  is  ia  the  same  heap  as  the  first 
argument  to  IVSCTOJ-SLT.  However,  in  this  example  since  the  cad  to  IVECTC2-ZLT  appears 
inside  a  call  to  a  non-OM  procedure  (i.e.  ♦),  the  RHeap  is  not  inserted. 

Note  that  the  cue  clause  in  the  specification  part  of  the  ItflTH-LPUIhTkS  has  just  two  elements: 
the  pseudo-variable  VaC  and  the  expression  (! PAIR- CAS  L).  Since  like  tPAIH-CDH,  IPAI&-CA1  is 
declared  to  the  pre-processor  to  return  an  object  in  the  same  heap  as  its  argument,  the  specification 
clause  will  be  filled  out  *o  be  the  full  triple,  the  last  element  being  the  RHeap  that  was  passed  to  P. 

While  we  have  not  actually  implemented  the  pre-procesaor  described  above,  we  do  not  believe 
that  the  implementation  would  be  all  that  difficult.  The  main  inconvenience  to  the  progamroer 
introduced  by  the  pre-procescor  is  one  that  is  found  in  any  system  of  declarations:  declaration  must 
precede  reference.  Lisp  systems  are  typically  more  flexible,  allowing  references  to  procedure  that 
have  not  yet  been  defined.  However,  this  flexibility  ir  possible  only  when  “compiling*  the  reference 
doc#  not  require  any  information  that  appears  in  the  definition.  The  pre-processor  does  require  such 
information,  and  fcesce  the  definition  must  precede  the  reference.  We  believe  that  this  is  not  too 
onerous  a  task  for  the  programmer. 


4.4  The  mixed  object  environment 

OM  runs  within  a  T  environment.  Programs  that  use  OM  can  create  normal  T  objects  (in  the 
transient  heap)  and  OM  objects  (in  a  permanent  heap).- 

OM  provides  primitives  for  copying  objects  between  the  transient  and  a  permanent  heap,  and 
between  permanent  heaps.  These  primitives  are  not  general  structure  traversers.  That  is,  they  do 
not  take  a  reference  to  an  object  cf  arbitrary  type  and  copy  that  object  aad  all  objects  reachable 
from  that  object  into  another  heap.  In  general,  with  a  large  graph  of  objects  (data  structures),  finer 
control  is  required;  when  copying  a  data  structure,  objects  will  need  to  be  allocated  in  different 
heaps.  No  simple,  single  copying  primitive  could  handle  all  possibilities  of  where  objects  are  to 
be  allocated.  Thus,  OM  provides  primitives  that  copy  atoms  (ircluding  LPcinters)  between  heaps. 
More  sophisticated  copying  procedures  can  be  built  out  of  the  primitives. 

Being  able  to  allocate  objects  in  the  transient  heap  and  then  later  copy  them  into  a  permanent  heap 
can  be  useful.  This  is  because  it  allows  one  to  write  procedures  that  allocate  new  objects  without 
regard  to  what  heap  the  objects  should  be  allocated  in.  This  may  be  a  convenient  programming 
style  for  certain  applications.  In  such  applications,  at  a  certain  level  of  abstraction  all  procedures 
that  allocate  new  objects  always  do  so  in  the  transient  heap;  at  the  next  higher  level  of  abstraction, 
the  objects  are  copied  into  the  appropriate  permanent  heap. 

Another  advantage  of  being  able  to  copy  transient  objects  into  a  permanent  heap  is  that  it  allows 
allocation  to  be  a  bit  more  reckless.  In  programs  that  allocate  objects  but  in  which  it  is  not  statically 
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possible  to  know  which  of  the  allocated  objects  will  be  permanent,  if  all  the  object  are  allocated  in 
a  permanent  heap,  some  would  be  garbage.  These  garbage  objects  are  costly  in  terms  of  garbage 
collection  time  (a  program  that  generates  a  lot  of  garbage  causes  the  garbage  collector  to  be  invoked 
more  frequently).  If,  however,  the  objects  are  always  allocated  in  the  tianiicat  heap  and  then  the 
ones  that  are  to  be  permanent  are  copied  Into  a  permanent  heap  sad  the  amount  of  garbage  is 
not  too  great,  the  garbage  is  ‘free’ .  A  program  that  creates  a  certain  amount  of  garbage  in  the 
transient  heap  can  do  so  with  no  time  penalty  if  it  doesn't  allocate  so  much  that  the  garbage  collector 
is  invoked  on  the  transient  heap  before  the  process  exits.  Since  the  transient  Leap  u  transient,  all 
itu  contents  are  by  definition  garbage  when  the  process  exits;  garbage  collection  on  that  heap  is 
implemented  simply  by  deleting  the  entire  heap.  Thus,  no  garbage  collection  time  penalty  (other 
than  the  time  required  to  delete  the  heap  file)  is  incurred. 

There  is  some  clumsiness  that  result*  from  writing  program  that  deal  with  both  OM  objects  and 
T  objects.  In  the  current  implementation  of  OM,  there  is  no  easy  way.  to  avoid  this.  In  another 
implementation  of  OM  we  expect  we  would  simply  dispense  with  T  objects  altogether  and  have  a 
unique  OM  transient  heap  associated  with  each  process.  This  heap  would  be  like  any  other  OM  heap 
except  that  the  maximum  size  of  its  heap  index  would  be  zero  -  i.e.  there  corid  be  no  references 
from  other  OM  heaps  ^  to  this  heap.  Thus,  when  the  process  exits,  the  heap  can  be  deleted.  This 
strategy  would  eliminate  the  clumsiness  of  dealing  with  the  T  transient  heap  without  sacrificing  the 
advantages  associated  with  that  heap  as  described  above. 

4.5  Finding  the  first  reference 

In  order  to  manipulate  an  object,  a  program  must  have  a  variable  whose  value  is  a  reference  to 
the  object.  But  when  a  program  starts,  the  values  of  all  its  variables  are  undefined.  How  does  a 
program  go  from  having  no  references  to  having  some  references? 

Programs  do  not  operate  in  a  vacuum.  Programs  are  started  because  people  want  them  started.  Peo¬ 
ple  give  arguments  to  programs.  If  the  programs  are  to  manipulate  permanent  state,  the  arguments 
must  indirectly  identify  objects  (if  they  did  not  name  objects,  the  program  could  not  conceivably 
manipulate  state).  However,  these  identifications  am  not  OM  reference*,  but  something  more  high 
level  -  something  that  is  meaningful  to  a  person,  e.g.  the  string  name  of  a  ‘mailbox*  or  a  number. 
The  problem  is  to  transform  the  kinds  of  arguments  people  give  into  references  to  objects. 

There  are  two  general  questions  involved  here.  First,  what  are  the  set  of  objects  that  are  known  a 
priori  by  the  system?  Second,  what  are  the  mechanisms  for  finding  other  objects  from  the  known 
objects? 


4.5.1  File  systems 

Traditional  computer  file  systems  provide  a  model  for  dealing  with  problem  of  finding  objects  given 
only  a  small  set  of  known  objects  and  some  logical  identification  of  the  desired  object.  The  objects 
in  a  traditional  file  system  are  directories  and  files.  The  known  object  is  typically  a  “root  directory* 
that  is  in  some  known  place  on  the  disk.  The  file  system  has  a  mechanism  for  finding  a  file  given 
the  string  name  of  a  file  and  the  root  directory. 

Filesystem  directories  are  a  simple  mechanism  for  converting  high  level  references  into  lower  level 
references.  However,  they  have  the  two  main  properties  b  which  we  are  interested.  First,  they  have 
a  piece  of  information  that  is  known  a  priori.  Second,  they  contain  system  maintained  functions 
and  data  structures  that  convert  high  level  references  into  lower  level  references. 

4.5.2  File  systems  as  a  model  for  OM  naming 

One  strategy  for  giving  high  level  names  to  OM  objects  is  to  implement  our  own  hierarchical  naming 
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system.  We  define  an  object  that  is  known  a  priori  by  OM  -  a  iinctory  object  -  that  map*  string 
names  onto  LPointcra.  A  directory  object  is  any  object  that  responds  to  the  DirectofyLooicvp 
operation  (that  takes  a  string)  by  returning  an  LPointer.  The  result  of  the  lookup  could  be  a 
reference  to  yet  another  directory  object,  or  to  a  k&f  in  the  directory  tree.  In  this  way,  an  object 

can  be  completely  named  with  a  list  of  strings.  Looking  up  an  object  given  a  list  of  strings  simply 
requires  traversing  the  tree  of  directory  objects  starting  at  the  root  directory  object  and  returning 
the  LPointer  that  was  the  result  of  the  last  lookup. 

Note  that  the  above  system  is  more  3 -ruble  than  a  tradition  filesystem  nstuing  system.  A  directory 
object  is  free  to  implement  DirectoryLooMp  in  any  way  it  chooses.  The  obvious  approach  would  be 
for  the  object  to  simply  maintain  a  hasih  table  mapping  strings  onto  L Pointers.  However,  it  could  do 
more  sophisticated  things.  The  object  might  treat  certain  strings  in  a  special  way.  For  example,  we 
could  make  a  directory  object  that  when  presented  with  a  person’*  name  yielded  a  person ’»  mailbox 
object.  However,  this  same  object  when  presented  with  the  string  “MyMailBcx*  would  yield  the 
mailbox  object  associated  with  the  person  that  own*  the  process  executing  the  operation. 

4.5.3  A  general  naming  strategy 

Note  that  this  hierarchical  naming  system  need  not  be  the  only  way  to  support  high  level  names. 
Different  applications  can  implement  different  systems.  OM  does  not  commit  applications  to  a 
particular  naming  system.  .411  that  Old  itself  must  supply  is  a  top  level  to  all  the  naming  systems 
-  i.e.  a  single  directory  that  maps  naming  system  names  onto  asmiay  system  objects:  an  entry 
point  into  a  data  structure  that  can  be  used  by  procedures  that  want  to  translate  high  level  names 
to  object  references.  The  hierarchical  naming  system  that  takes  a  list  of  strings  and  produces  an 
LPointer  is  simply  one  naming  system  in  the  top  level.  This  naming  system  can  be  entered  in 
the  top  level  under  some  well  known  name  (e.g.  ‘TVeeNames*);  the  value  of  this  entry  is  the  root 
directory  object  for  the  naming  tree. 

4.5.4  Naming  in  ih&  current  implementation 

The  current  implementation  of  OM  does  not  include  the  general  top  level  naming  system  name 
table  described  above.  Since  GM  is  running  on  top  a  conventional  file  system  that  has  a  hierarchical 
naming  system,  we  took  advantage  of  that  naming  system.  The  DOMAIN  naming  system  lets  us 
name  heaps.  However,  we  still  need  to  identify  a  particular  object  in  the  neap. 

In  early  versions  of  OM  we  allowed  procedures  to  treat  the  heap  index  as  a  record  with  named  fields. 
The  names  were  artifacts  of  the  source  code  and  were  sot  stored  in  the  heap  itself.  This  system 
is  analogous  to  records  in  Algol-like  languages:  a  program  refers  to  a  field  of  record  by  name,  but 
when  the  program  is  compiled,  the  names  disappear  and  the  field  is  identified  limply  by  its  offset 
from  the  beginning  of  the  record.  In  OM,  elements  of  the  index  could  be  given  symbolic  names; 
these  names  could  be  used  in  conjunction  with  an  R II tap  to  obtain  an  element  of  the  index.  The 
symbolically  named  elements  of  the  index  were  excluded  from  the  pool  of  index  elements  that  are 
assigned  as  a  result  of  EXPORT-P-POINTZIt.  Using  this  record-like  scheme  •  first  reference  could  be 
obtained  simply  by  activating  a  heap  (using  its  path  name)  and  referring  to  one  of  the  symbolically 
declared  heap  index  elements. 

The  problem  with  the  scheme  as  we  implemented  it  was  that  there  was  no  way  to  be  sure  that  a 
symbolic  name  was  not  being  used  to  retrieve  and  element  from  the  index  of  a  heap  that  was  not  of 
the  right  ‘type*  (i.e.  that  the  particular  elements  of  the  heap  index  were  not  reserved  for  references 
by  the  particular  set  of  symbolic  names).  The  problem  is  analogous  to  one  that  would  arise  if  in 
Pascal  a  field  name  from  any  record  type  could  be  used  after  a  name  of  a  variable  whose  type  was 
any  record  type.  E.g.  in: 

type  rl  -  raeord 

a:  inttgsr ; 
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b:  iatsgar; 
rad; 


type  r3  •  record 

z:  char; 
y:  integer; 
aad; 

nr 

▼1:  rl; 

▼2:  r2; 

begin 

▼l.y  :•  0; 

•ad 

tb«  reference  to  vl.y  is  invalid.  But  in  the  system  we  implemented  in  OM,  this  sort  of  illegal 
reference  would  go  undetected.  The  cause  of  the  problem  is  that  heaps  are  not  typed.  However,  if 
we  associated  a  type  code  with  each  set  of  symbolic  index  element  names  aad  we  stored  this  type 
code  in  all  heaps  for  which  we  wanted  to  allow  index  elements  to  be  referred  to  symbolically,  then 
references  through  symbolic  element  names  could  be  dynamically  checked  to  see  if  they  were  being 
applk  i  to  the  right  type  of  heap. 

Instead  of  implementing  this  typing  system,  we  abandoned  the  record-like  approach  to  the  heap 
index.  OM  already  has  a  type  system  and  there  is  no  point  in  introducing  another  one. 

The  current  OM  naming  systems  consists  of  a  facility  that  allows  the  programmer  to  identify  one 
iistinfeuked  object  per  heap.  The  distinguished  object  mechanism  is  a  way  of  specifying  and 
obtaining  a  known  object  within  a  heap.  A  heap’s  distinguished  object  can  be  obtained  simply  by 
having  the  heap’s  HID.  The  OM  primitive  DISTINGUISHID-aEFEXESCE  takes  an  RHcap  (gotten  by 
activating  a  heap)  and  returns  an  RPointer  to  the  heap’s  distinguished  object.  When  used  in  the 
context  of  the  SET  special  form,  DISTINGUISHED- XETEXEICE  can  be  used  to  set  a  heap’s  distinguished 
object.  In  this  context,  the  program  must  supply  an  RPointer  to  the  primitive. 

3efore  the  distinguished  object  mechanism  can  be  used  it  is  necessary  to  get  the  HID  of  some 
heap.  In  the  current  naming  system  implementation,  HIDs  can  be  obtained  using  the  OM  primitive 
FILE-NAXE-HID.  This  primitive  takes  a  DOMAIN  path  name  and  produces  the  HID  of  the  heap 
that  has  that  path  name.  Using  DISTXNCUISHED-XETEXENCE  and  FILE-NAMZ-HID  it  is  possible  to 
get  a  reference  to  a  known  object.  Thus,  DOMAIN  path  names  are  the  logical  names  of  the  known 
OM  object. 


4.6  Sample  applications 

To  see  how  usable  the  design  and  implementation  OM  is,  we  built  two  sample  applications  that 
use  OM.  These  applications  are  representative  of  the  kinds  of  applications  OM  is  designed  to  handle. 

4.6.1  OM/UMail 

UMail  is  a  display-oriented  electronic  mail  user  interface  program  that  runs  on  the  DOMAIN  system. 
UMail  lets  users  send  messages  and  receive  and  store  messages  in  mall  boxes.  UMail  does  net  use 
OM;  OM/UMail  does.  In  UMail  mail  boxes  are  stored  in  simple  text  files.  When  UMail  starts,  it 
reads  and  parses  the  text  file  into  an  internal  data  structure.  When  UMail  exits,  it  rewrites  the 
text  file  if  the  contents  of  the  internal  representation  of  the  mail  box  changed.  The  cost  of  the  parse 
and  rewrite  steps  is  barely  tolerable  for  moderately  large  (50-100  message)  mail  boxes.  Elec'ronic 
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bulletin  boards,  a  sub-clast  of  mail  boxes,  an  general  larger  and  using  UMail  to  examine  them  is 
virtually  impcaabk.  This  was  one  of  tbs  masons  that  made  us  to  want  to  make  an  OM  version  of 
UMail. 

In  UMail,  the  internal  representation  of  a  mail  box  is  a  “mail  box  object*.  This  object  handles 
certain  operations;  e.g  ScltxCJsg,  All2.hq,  Dtitithlaj,  EspvngeDetei&dMagt.  The  local  state  of  a 
mail  box  consists  of  a  list  of  “message  objects*.  A  message  object  handles  the  operations:  ImtMag 
and  Print  The  local  state  of  a  message  object  includes:  the  text  of  the  massage,  pointers  to 
various  interesting  headers  in  the  text;  internal  tiers  representing  the  date  the  matin:.  ;e  was  seat 
and  delivered;  and  Saga  (e.g.  *ni'a;  5  to  be  deleted’ }. 

The  changes  necessary  to  turn  UMail  into  OM/UMail  were  relatively  straightforward,  if  tedious 
(lacking  the  pre-processor).  The  conversion  went  far  enough  to  demonstrate  that  we  c.  i  maintain 
the  OM  versions  of  the  mail  box  and  message  object-  An  entire  mail  box  object,  with  all  the 
messages  it  references,  is  kept  in  a  single  heap.  One  heap  contains  exactly  one  mail  box.  The  Erst 
reference  is  obtained  by  constructing  the  DOMAIN  path  name  of  the  heap  £le  from  the  logical 
(abstract)  name  of  the  mail  box  (e.g.  a  bulletin  board  or  user  name),  activating  the  heap,  and 
following  the  heap’s  distinguished  reference,  which  refers  to  the  moil  box  object. 

OM/UMail  did  not  replace  UMail  as  the  production  mail  user  interface.  We  stopped  working  on 
OM /UMail  as  it  became  apparent  that  ve  could  learn  more  about  how  w»i]  OM  works  from  designing 
and  implementing  an  application  from  scratch,  rather  than  converting  an  existing  application. 


4.6.2  Naming  server 

The  second  sample  application  to  use  OM  is  a  naming  database  manager  (NDBM).  We  use  the  terms 
‘database*  and  ‘database  manager*  in  a  very  general  sense  -  as  terms  that  mesa  “a  collection  of 
permanent,  structured  data*  and  ‘a  set  of  programs  that  manipulate  that  data*. 

The  motivation  for  the  NDBM  project  was  to  replace  the  DBM  available  on  a  DECSYSTEM-20  in 
the  Yale  Computer  Science  Department.  The  data  held  in  the  DEC- 20  database  includes: 

•  Personal  informatioa.  E.g.  peoole's  home  address  and  phone  number,  user  ID*,  electronic 
mailing  addraaes. 

•  Host  (computer)  information.  £.g.  host  nicknames,  network  addresses. 

•  Mailing  list  information.  Members,  maintainen  and  descriptive  information  about  electronic 
mailing  list*. 

The  DEC-20  DBM  is  written  in  Lisp.  The  permanent,  external  representation  of  the  database  is  a 
single,  large  text  file  containing  the  printed  representation  of  a  *ir.;k,  large  Lisp  list.  When  the  DBM 
starts,  it  reads  and  parses  the  file  into  a  Lisp  list,  the  internal  representation  of  the  database.  The 
time  to  read  and  write  the  database  is  very  long.  The  data  is  not  simultaneously  rh arable  among 
several  processes.  Access  to  the  data  is  by  a  network  server  process  that  handles  one  transaction 
at  at  time  from  other  processes.  The  user  interface  to  the  database  manager  is  one  of  these  other 
processes. 

The  DEC-20  DBM  uses  the  relational  model.  However,  the  generality  of  the  relational  approach 
was  never  exploited.  One  reason  for  this  is  that  the  generality  was  not  needed.  Another  reason  is 
because  the  DBM  implementation  is  not  very  sophisticated,  and  the  time  to  execute  the  relational 
operations  is  quite  high. 

The  implementation  of  NDBM  is  in  no  way  based  on  the  DEC-20  DBM.  However,  the  NDBM  is 
designed  to  hold  the  same  data  as  the  DEC- 20  DBM. 

In  designing  the  NDBM  we  viewed  the  task  as  a  permanent  data  structure  problem,  rather  than 
as  a  traditional  database  design  problem.  The  database  is  relatively  small  (several  hundred  people, 
several  hundred  hosts,  a  hundred  mailing  lists)  and  we  were  not  interested  in  applying  sophisticated 
database  technology. 
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In  thinking  about  the  problem  of  storing  the  kind*  of  data  we  needed  to  store,  we  developed  a  way 
of  thinking  about  stucturing  data  in  general,  rather  than  structuring  the  particular  data  at  hand. 
As  a  result,  the  NDBM  is  a  more  a  DBM  framework  than  ar  actual  DBM.  It  is  a  framework  in  the 
sense  that  it  defines  a  set  of  operations  and  their  semantics,  but  does  not  supply  the  implementation 
of  the  operations.  It  does  not  specify  any  properties  of  the  data  to  be  stored  in  the  database.  An 
instinct  of  s  framework  is  a  set  of  objects  that  behave  in  the  way  specified  by  the  framework. 

The  framework  defines  two  sets  of  types  of  objects:  item  sad  descriptor.  A  type  is  in  the  set  of  item 
types  if  it  responds  to  the  operations  defined  on  item  types.  Item  types  are  analogous  to  record 
types  in  a  conventional  database.  Item  objects  -  Le.  objects  whose  type  is  an  item  type  -  are  like 
records  in  a  traditional  database.  The  local  state  of  an  item  object  contains  information  about  the 
entity  being  ocscribed  by  the  object. 

For  example,  an  instance  of  the  framework  might  have  a  type  called  Ptnon  which  is  in  the  set  of 
item  types.  Each  person  in  the  instance  is  represented  by  a  single  object  whose  type  is  Person.  A 
Ptnon  object  presumably  contains  strings  containing  a  person’s  home  address,  phone  number,  etc. 

Item  objects  can  also  contain  references  to  other  item  objects.  E.g.  a  MtUingLUt  object  can  have  a 
list  of  Ptnon  and  MailingLitt  objects. 

A  type  is  in  the  set  of  descriptor  types  if  it  responds  to  the  operations  defined  on  descriptor  types. 
Descriptor  types  are  used  to  create  and  organise  item  objects.  Every  descriptor  type  has  exactly 
one  associated  item  type.  Descriptor  objects  -  Le.  objects  whose  type  is  a  descriptor  type  -  are 
like  database  schemas  in  a  traditional  database.  The  local  state  of  a  descriptor  object  presumably 
contains  data  structures  that  allow  individual  items  to  be  stored  and  retrieved.  We  say  that  a 
descriptor  object  covtn  a  set  of  item  objects.  A  descriptor  object  coven  an  item  object  if  it  is 
possible  to  obtain  a  reference  to  the  item  object  by  applying  the  lookup  operation  to  the  descriptor 
object. 

Descriptor  types  must  handle  operations  like: 

Item  Tfft:  Return  the  item  type  associated  with  the  descriptor  type. 

NtvIUm. :  Create  and  return  a  new  item;  add  the  item  to  the  descriptor  index  (lookup  table). 
Lookvglttm:  Given  a  key  (e-g.  a  string),  return  the  item  object  associated  with  that  key. 
WalklUms:  Apply  a  procedure  (passed  ss  an  argument)  to  all  the  items  that  the  descriptor  object 
covers. 

Show:  Produces  a  printed  representation  of  all  the  items  the  descriptor  object  coven. 

Item  typee  must  handle  operations  like: 

DeteriplorTgf*:  Return  the  descriptor  type  associated  with  the  item  type. 

Show:  Produce  a  printed  representation  of  the  item  object’s  contents. 

In  any  instance  of  a  framework,  both  item  and  descriptor  types  are  free  to  handle  additional  op- 
orations.  For  item  types,  it  is  expected  that  they  will  handle  all  sorts  of  operations  peculiar  to 
the  instance.  E-g.  an  instance  containing  the  Ptnon  item  type  described  above  would  presumably 
handle  an  operation  to  retrieve  a  Ptnon  object's  home  address  string. 

The  framework  imposes  a  convention  on  how  objects  in  an  instance  should  he  spread  out  across 
heaps.  The  convention  is  that  there  is  exactly  one  heap  per  item  type  in  the  instance.  All  the  objects 
of  the  same  item  type  reside  in  a  single  heap.  The  descriptor  object  that  covers  the  item  object 
resides  in  the  same  h<*ap.  There  is  one  additional  heap,  called  the  master  keep,  that  contains  only 
one  object:  a  vector  of  all  the  descriptor  objects  in  the  instance.  The  master  heap’s  distinguished 
reference  points  to  this  vector. 

We  implemented  an  instance  of  the  framework  that  is  designed  to  hold  the  kinds  of  data  in  the 
DEC-20  database.  We  then  moved  virtually  all  the  contents  of  the  DEC-20  database  into  the 
instance  of  the  framework.  The  instance  has  eight  type:  four  descriptor  types  and  four  item  types. 


70 


M&nagiDi  Permanent  Objects 


The  four  item  types  are:  Person.  Host,  MaHimfLut,  and  UserlD",  t he  four  descriptor  types  are: 

■PerMisI/sse,  BoetDeac,  AlaiiiagListDeoc,  and  EstrlDDuc  The  descriptor  types  support  translation 
between  string  keys  (e..j.  a  person's  name)  and  references  to  item  object*  by  using  hash  tables  that 
are  part  of  tbs  local  state  of  the  descriptor  objects.  Descriptor  type*  a ho  support  operations  that 
allow  modification#  to  be  made  to  item  objects  interactively. 

When  a  user  invokes  a  procedure  to  view  or  modify  some  piece  of  the  database,  one  or  more  heaps 
may  be  activated.  The  heaps  are  activated  for  exclusive  use  -  for  the  deration  of  the  activation,  no 
other  process  caa  access  the  same  part  of  the  database.  This  may  seem  like  a  serious  restriction, 
but  considering  that  user*  were  quite  able  to  live  with  the  strictly  oce-at-a-time  access  offered 
by  the  DEC-20  DBMS,  the  restriction  is  actually  net  too  serious.  In  NDBM,  multiple  processes 
caa  simultaneously  access  part#  of  the  database  as  long  as  the  parts  are  in  different  heaps.  More 
concurrency  could  be  accomodated  by  using  one  of  the  techniques  discussed  earlier.  However,  given 
the  nature  of  the  access  patterns  (infrequent  and  abort),  the  current  scheme  seem*  satisfactory. 


4.7  A  mor-2  ambitious  scheme 

In  this  section  we  describe  a  scheme  for  making  the  application  programmer’*  task  considerably 
easier  than  it  is  in  the  currant  OM  implementation.  This  icheme  involves  uring  special  compiler 
optimization  techniques  to  make  certain  apparently  expensive  operations  free. 


4.7.1  Active  References 

At  the  application  level,  let  us  replace  the  concepts  of  RPointera  and  RHeap*  with  a  single  concept: 
active  reference  (ARef).  At  the  OM  implementation  level,  an  ARef  is  a  T  object  (he.  mot  an  OM 
object).  ARefs  never  reside  in  OM  heaps.  An  ARef  Is  an  aggregate  -  its  representation  is  not 
immediate,  it  resides  in  the  transient  heap. 

An  ARef  contains  an  RPointer  and  an  RHeap  -  but  this  of  no  concern  to  the  programmer.  We  say 
that  an  ARef  contains  an  RPointer  and  RHeap  so  that  we  can  describe  the  ARef  approach  in  terms 
of  primitives  we  have  already  discussed.  These  primitives  wiil  no  longer  be  used  by  the  programmer. 

ARef*  are  like  LPointers  in  that  they  completely  specify  some  OM  object.  ARefs  are  active  in 
the  sense  that  they  apply  only  vo  some  particular  active  heap.  An  ARef  is  meaningful  only  in  the 
context  of  a  particular  process. 

We  can  introduce  a  layer  of  abstraction  that  uses  ARefs  ;nstead  of  RPointer*  and  RHeap*.  For 
example: 

(DEFINE  (AXEF-EXAMINS  AXE?  I) 

(MAKE -ARE?  (XPOINTEX-EXAMINE  (AXEF-XPOISTEX  AXE?) 

(AXE7-X3EAP  AXEF) 

I) 

(AREF-R3EA?  A/RE? )  )  ) 

Where  MAXE -AXE?  takes  an  RPointer  and  an  RHeap  and  makes  (i.e.  allocates  in  the  transient  heap) 
*n  ARef.  AXE7-RP0IXTEX  extracts  an  ARef’*  RPointer  and  AXEF-XHXAP  extracts  an  ARef’*  RHeap. 
Thus,  AXE? -EXAMINE  takes  an  ARef  and  an  offset  into  an  object  and  returns  an  ARef  to  the  object 
referenced  from  the  Ith  slot  of  the  object  referenced  by  AXE?. 

IPAIX-CAX  can  be  defined  in  terms  of  AXE? -EXAMINE  instead  of  XPOINTEX-EXAMINE. 


(DEFINE  (IPAIX-CAX  OBJ) 
(AXEP-EXAMINE  OBJ  0) 
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This  new  IPAXN-CAN  now  looks  mote  like  T't  ordinary  CAN  than  the  old  I PAIN-CAX  does  because 
the  new  one  takes  just  one  argun^nt.  Thus  we  have  solved  the  two  argument  problem  without 
resorting  to  a  pre-processor. 

We  need  to  define  ANET-DEPCblT  to  serve  the  same  function  for  ARefs  that  NPOINTEN-DEPOSIT 
serves  for  RPointers: 


(DEE IMS  (ANEP-DEPOSIT  A2EF1  I  A2EE3) 

CRPOirrei-DEPCSIT  (ANEF-NPOXNTEN  AKEFi) 

(A12T-IKZA?  ASEF1) 

I 

(anep-ipointzn  anees) 

(jlxzt-isza?  anees))) 

This  procedure  sets  the  Xth  slot  of  the  object  referred  to  by  A1Z71  to  be  the  object  referred  to  by 
ARIFS. 

But  there  is  a  price  for  the  A  Ref  approach.  One  price  is  in  the  extra  layer  of  indirection  it  introduces. 
But  more  importantly  it  is  expensive  in  terms  of  storage  in  the  transient  heap.  To  simply  extract  a 
field  (e.g.  the  car)  of  an  object  (e.g.  an  OM  pair)  requires  an  A  Ref  to  be  allocated  in  the  transient 
heap.  The  cost  of  this  is  unacceptably  high.  But  there  is  a  way  to  avoid  the  cost. 


4.7.2  A  smart  compiler 

Consider  the  normal  T  expression: 

(LET  ( jC  (CONS  expression- i  axpresaion-2))) 

(♦  (CAN  X)  (COE  X))) 

It  seems  clear  that  since  the  tana  ceil  constructed  in  this  expression  is  never  passed  to  a  procedure 
that  might  store  away  a  reference  to  the  cell,  a  clever  compiler  that  knows  the  meanings  of  the 
procedures  CONS,  CAN,  and  CON  could  transform  the  above  exp  read  on  into: 

(LET  ((X-CAN  expression- 1) 

(X-CON  expression-3) 

(♦  X-CAN  X-CON)) 


applying  a  procedure  similar  to  reduction  in  strength. 

Now  consider  the  expression: 

( I PAIN-CAN  (1 PAIN-CAN  OBJ)) 

The  inner  I  TAIN-CAN  allocates  and  returns  an  A  Ref.  This  A  Ref  is  pissed  to  the  outer  I  PAIR-CAN 
and  then  becomes  garbage  (since  I  PAIN-CAN  will  not  store  the  ARaf  in  any  object).  Baaed  on  the 
definition  of  I  PAIN-CAN,  we  can  rewrite  the  above  expression  tc 

(LET  ((P  (AAEE-EXAXINE  OBJ  0))) 

(AAXE-EXANIME  P  0)) 


Baaed  on  the  definition  of  ANEE-EXAMIMZ,  we  can  rewrite  tbe  above  expression  as: 
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(ist  ((?  qv&z-asz?  cspoiam-miGsr  (AisF-epoirra  osj) 

(ASEF-RSZA?  03  J) 

0) 

UazF-assA?  oaj)))) 

Ouxz-xszt  (R?oiiiT22-mMiK:  outEF-aprinrra  ?) 

Oeef-helap  ?) 

0) 

CARZF-E22A?  P))) 

Using  the  compiler  technique  described  above,  since  the  A  Ref  held  in  P  is  not  saved  away,  we  know 
that  we  can  safely  eliminate  the  first  iUEE-ABEF,  resulting  is: 

(let  ((p-apourm  (spoiittss-exajjdje  (aref-voixter  csj) 

(ASZF-RELA?  u2J) 

0)) 

(P-iHEAP  (ARZF-M2A?  0£J))) 

OttXZ-AEZF  (RP0I3T2S-EXAMIE2  ?-£?CiaTE2 

P-E2A? 

C) 

P-H2A?) ) 

Now  we  have  allocate*  only  one  A  Ref  instead  of  trvo.  If  the  original  expression  is  embedded  is 
(say)  another  I  PAIR-CAR,  still  only  one  ARef  will  be  allocated  as  both  inner  KAXE-ASEFs  will  be 
eliminated. 

If  we  implement  the  proposed  compiler  technique,  we  can  re-introduce  the  into  rattle  dereferencing 
of  LPointer*  deocribed  in  section  4.2.1.  Now  however,  instead  of  automatically  creating  an  LPointer 
to  return,  we  create  an  A  Ref.  We  redefine  AAE7-EXAKI2S  to  check  for  an  ARcTs  pointing  to  an 
LPointer: 

(DEFIEZ  (A1EP-EIAMI3SE  AREF  I) 

(LET  ((S?  (AREF-VOIHTER  AREF)) 

(3  (AREF-RHEAP  AREF))) 

(I?  (lpcirter?  a?) 

(ma-LPCimi  ((?  2?  h)) 

(MAXE-ARZ7  (8P01STE.VECAHIH2  PI*  PIS  I)  PIS)) 

(MAES- AREF  (RPOIHTSR-EXAh'ISE  R?  H  I)  B)))) 

To  make  AAEF-DEFCSIT  do  the  right  thing  in  case  the  two  ARef*  it  is  passed  refers  to  objects  that 
are  no*  in  the  same  heap,  it  must  be  defined  to  create  an  LPointer  that  case: 

(DEFIJJE  (AREF -DEPOSIT  AXS71  I  A2ZF2) 

(LET  C(XPi  (AREF-RP028TES  AREF1)) 

(HI  (AAEF-HEEAP  AREF1)} 

(P-P2  (AREF-RPOIITTER  AREF2)) 

(32  (AREF-RHEA P  ARZF2) )  ) 

(CCHD  ((-HI  H2) 

(RPOIKTER-DEPOSIT  API  HI  I  R?2  H2)) 

(T 

(RP0INT2R-DEPCSIT 
VI  HI 
I 

(AAEF->L?OI)frai  A1E72  HI)  HI))))) 

(DEFIHZ  (AAE7->LPOIXTER  A REF  H) 

( I  EXPO RT-RPO INTER  (AREF -RPO INTER  AREF)  (AAEF-tHEA?  AREF)  H)) 
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If  the  heap  of  the  target  object  (A1EP1)  »  the  tame  as  the  beep  of  the  source  object  (A*£?2)  - 
the  object  a  reference  to  which  is  being  deposited  -  then  tbe  slot  in  the  object  is  simply  set  to  the 
RPointer  to  tbe  source  object.  Alternatively,  if  tbe  source  and  target  objects  are  not  in  tbe  same 
heap,  an  LPointer  must  be  created  in  tbe  target  object’s  heap;  tbe  LPointer  must  point  to  tbe  source 
object.  AM?- LPOINTER)  is  simply  a  procedure  that  allocates  an  LPointer  to  tbe  tame  object  that 
tbe  A  Refs  refers  to.  Note  that  we  can't  simply  store  the  ARef  in  tbe  target  object’s  heap  because 
an  ARef  is  not  a  process  context  independent  quantity  (because  it  contains  an  RE  cap)  and  it  does 
not  refer  through  tbe  beap  index. 

4.7.3  Active  references  and  heap  activation 

We  can  further  extend  tbe  ARef  scheme  to  ma>  j  the  activation  of  heaps  transparent  to  the  pro¬ 
grammer.  The  general  idea  is  to  automically  control  what  heaps  are  mapped  into  tbe  process  virtual 
address  space.  When  an  object  in  a  beap  needs  to  be  examined,  tbe  beap  has  to  be  activated.  If 
there  is  room  in  tbe  virtual  address  space,  tbe  beap  is  simply  mapped.  If  there  is  not  room,  then 
some  already  mapped  beap  must  be  “bumped*  -  i.e.  forcibly  unmapped  to  make  room  for  another 
heap. 

Recall  that  tbe  RHeap  data  structure  co.  ins  a  HID  and  an  RHeapB.  Tbe  RHeapB  is  tbe  active 
heap’s  base  address  in  tbe  process  virtual  address  space.  Suppose  that  when  a  heap  is  bumped,  we 
iet  tbe  RHeapB  field  of  tbe  RHeap  to  be  sti 1L  Sines  only  one  RHeap  structure  is  allocated  for  a 
single  active  beap,  all  tbe  ARefs  will  refer  o  a  beap  via  a  single  RHeap  structure.  Thus,  we  can 
modify  AXEF-EXAMIXZ  (and  similarly  A*EP -DEPOSIT)  to  be: 

(DEPIIE  (AIEf-EXAXIHE  A1EP  I) 

(ixr  ((*?  (Auy-Rpoirrzi  axze)) 

(H  (A*EF-*HEAP  IET))) 

(IP  0 TOLL?  (XHXAP-BASE  Hi) 

( IZACTIVATE- HEX?  H)) 

(If  (LPOIHTEXT  *?} 

( l«TB-LPODrna  ((?  IT  *)) 

(MAKZ-AJtXf  (l?Cim»-EXAHI*Z  PI*  PII  I)  PI*)) 

(MAxz-Axrr  (*poirrEx-EXA««  *?  i  i)  *)))) 

*ZACTTVAT2-HEAP  simply  remaps  tbe  beap  indentifieu  by  tbe  RHeap’s  HID  field  and  updates  ihe 
RHeap  structure’s  RHeapB  field  to  contain  tbe  address  at  which  tbe  heap  is  remapped.  Note 
that  AEACTIYATE-KEAP  takes  an  RHeap,  while  ACTXfATZ-BEA?  takes  a  HID.  Toe  only  times  that 
ACTIVATE- BEAP  would  be  called  is  in  tbe  case  of  sc.  LPointer  being  dereferenced  (i.e.  as  a  result  of 
executing  HflTl-LPOIHTE*  expression  in  AAEP-EXAMIHX),  or  in  some  “first  reference"  case. 

ACTIVATE- HEAP  needs  to  be  modified  to  check  the  amount  of  free  virtual  address  space,  and  deacti¬ 
vating  heaps  if  necessary  to  make  room.  Ideally,  heaps  should  be  deactivated  using  a  “least  recently 
used"  (LRU)  strategy.  Supporting  LRU  would  require  exporting  some  page  reference  information 
from  Aegis.  Alternatively,  a  simple  active  heap  FIFO  might  be  sufficient  to  manage  the  addresr. 
space.  This  is  an  area  for  future  research. 


4.7.4  Object  allocation 

It  is  still  the  responsibility  of  tbe  programmer  to  decide  in  what  heap  an  object  should  be  placed. 
Tbe  allocation  procedure*  still  take  an  argument  specifying  in  wbat  heap  the  new  object  should  be 
created.  There  is  not  a  "right"  or  “wrong"  place  to  pr'  an  object.  Rather  there  are  more  or  lens 
optimal  places.  Tbe  optimal  placement  of  an  object  is  one  tbai  minimises  the  number  of  LPointer* 
to  the  object.  That  is,  in  general,  an  cbject  should  be  place  in  the  heap  that  contain*  the  most 
references  to  the  object.  Placing  an  object  in  a  sub-optimal  place  will  not  cause  a  program  to  behave 
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m  >ctly;  it  will  simply  increase  the  execution  time  of  the  program  and  the  amount  of  heap  space 

life’ 

C.V.n  Benefits  and  costs 

The  A R.  i  approach  is  not  in  conflict  witn  the  approach  of  storing  objects  in  multiple  heaps  and 
having  two  kinds  of  references.  However,  the  A  fief  approach  simplifies  the  application  programmer’s 
job  sirce  it  relieves  him  of  the  chores  of: 

•  Following  the  RPointer/RHeap  argument  convention; 

•  Managing  LPointers,  and 

•  Activating  and  deactivating  heaps. 

The  pre-processor  approach  eliminates  only  the  first  cf  these  chores.  But  even  in  that  chore,  it 
imposes  more  work  on  the  programmer  than  does  the  A  Ref  approach. 

The  ARef  approach  has  two  main  costs.  First  it  requires  a  sophisticated  compiler  that  applies  the 
optimization  discussed  above.  The  compiler  must  reliably  detect  the  cases  that  can  be  optimized. 
If  it  fails  to  detect  a  case,  an  unnecessary  ARef  will  be  allocated.  If  the  case  is  in  the  middle  of 
a  loop,  many  unnecessary  ARefs  may  be  allocated.  The  investigation  of  the  compiler  techniques 
involved  here  are  beyond  the  scope  of  this  work. 

Note  that  the  cost  of  the  sophisticated  compiler  is  in  both  compiler  development  and  compiler 
execution  time.  The  former  cost  is  paid  just  once,  but  it  is  high  enough  that  we  were  not  willing 
to  pay  it  for  this  project.  The  latter  cost  is  the  increased  execution  time  incurred  by  the  logic  that 
detects  the  optimization  we  have  described.  However,  this  cost  can  be  reduced  by  not  applying 
the  optimization  on  versions  of  the  procedures  that  are  in  the  debugging  phase.  Once  debugging  is 
complete,  the  expensive  compilation  can  be  performed  -  once. 

Another  cost  of  the  ARef  approach  is  that  the  cost  of  the  accessors  goes  up.  AitSF-EXAHIHE  has  two 
more  tests  -  one  to  see  if  an  ARef  refer*  to  an  LPointer,  and  one  to  insure  that  the  heap  is  active 
-  than  3tPOINTZB.-£XAiiI5fa.  This  cost  is  in  both  code  size  and  execution  time.  Given  the  size  of  the 
definition  of  AHZF-EXAJCDIE,  we  are  unwilling  expand  it  inline  at  each  occurrence  of  an  accessor.  The 
alternative  is  to  use  a  procedure  call.  If  we  do  this,  the  cost  of  the  ARef  approach  is  only  execution 
time.  Note  that  compared  with  other  existing  object-based  systems  (c.g.  Smalltalk  and  Hydra),  the 
cost  of  accessing  a  slot  in  an  object  is  still  fairly  cheap. 


Chapter  5 

Conclusion 


5.1  Reviewing  the  problems  and  their  solutions  in  OM 

la  chapter  2  we  described  the  problems  that  arise  ia  a  system  that  needs  to  store  data  permanently. 
We  will  now  review  the  problems  discussed  there  and  bow  OM  addresses  them. 


5.1.1  Integrity  and  atomicity 

OM  guarantees  the  integrity  of  data  against  logical  program  error  by  presenting  a  consistent  pro¬ 
grammer  interface.  This  interface  insures  that  programs  can  access  data  in  heaps  only  using  the 
primitives  that  insure  integrity. 

OM  does  not  address  the  problems  that  result  from  hardware  errors  or  disasterous  software  errors 
(e.g.  system  crashes).  Thus,  the  potential  for  loss  of  data  integrity  is  present  if  such  errors  occur. 
We  feel  that  this  limitation  does  not  make  OM  unusable  since  users  already  deal  with  this  sort  of 
loss  of  data  due  to  such  errors. 

OM  does  not  support  atomic  operations.  However,  we  aee  the  current  OM  system  as  a  vehicle  on 
which  systems  that  support  atomic  operations  can  be  built. 

5.1.2  Abstraction 

OM  supports  abstract  access  to  data  using  the  object-oriented  programming  model  and  the  type  sys¬ 
tem  we  described.  This  allow*  programmers  to  ignore  issues  of  disk  and  file  formatting.  Application 
programs  access  data  using  operations  that  are  logical  and  abstract. 

5.1.3  Storage  control 

Storage  ia  controlled  in  OM  using  the  heap  model  and  garbage  collection.  The  time  required  to 
allocate  a  piece  of  storage  (excluding  garbage  collection  overhead)  ia  small.  Heaps  can  be  garbage 
collected  independently  making  the  use  of  garbage  collected  storage  feasible.  The  heap  model 
seems  to  be  a  natural  one  for  the  class  of  application  programs  whose  data  structures  are  naturally 
parti  tionable. 


5.1.4  Sharing  and  concurrency 

In  OM,  objects  can  be  shared  among  users  and  applications  that  use  the  interface  presented  by  OM. 
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Since  heaps  are  baaed  on  DOMAIN  file*  which  are  page-faulted  on  demand,  only  these  objects  that 
need  to  be  accessed  are  ever  read  into  main  memory. 

OM  supports  concurrency  as  well  as  the  DOMAIN  system  does.  That  is,  application  programs  can 
use  the  DOMAIN  synchro  nil  alien  primitives  to  control  concurrent  access.  For  highly  concurrent 
processes,  we  suspect  that  these  primitives  are  too  expensive. 


5.1.5  Security 

OM  uses  the  DOMAIN  access  control  primitives  to  insure  security  at  the  heap  level.  Access  to 
individual  objects  can  not  be  controlled.  For  the  kinds  of  applications  we  have  in  mind  for  OM  (e.g. 
the  ones  we  described  as  samole  uses  of  OM)  this  restriction  is  not  a  serious  problem. 


5.1.6  Reliability 

OM  does  not  address  issues  of  reliability. 


5.1.7  Performance 

In  the  design  and  implementation  of  OM,  we  have  stressed  performance  over  reliability  and  availabil¬ 
ity.  We  built  a  system  that  makes  accessing  permanent  objects  nearly  as  cheap  as  non-permanent 
objects.  In  using  OM,  programmers  do  not  need  to  use  special  techniques  (e.g.  buffering)  to  increase 
performance. 


5.1.8  Reference 

OM  has  two  kinds  of  references:  local  (RPointers)  and  non-local  (LPointers).  Local  references  are 
small  and  fast  to  dereierence.  Non-local  references  are  larger  and  more  expensive  than  local  refer¬ 
ences.  OM’s  local  references  are  smaller  and  cheaper  than  the  references  used  in  many  permanent 
object  systems.  The  combination  of  RPointers  and  LPointers  allow  programs  to  be  as  emeient  as  in 
conventional  programming  systems  in  which  all  the  objects  are  in  a  single  (relatively  small)  address 
space,  while  supporting  a  very  large  number  of  permanent  objects. 

Having  two  kinds  of  references  creates  some  problems  for  the  programmer.  We  outlined  several 
techniques  for  making  the  fact  that  there  are  two  kinds  of  references  nearly  transparent  without 
giving  up  the  advantages  of  the  two  reference  scheme. 


5.2  Design  Philosophy 

We  approached  the  problem  of  a  permanent  object  storage  system  with  a  very  practical  orientation. 
We  used  existing  hardware  and  operating  system  software.  We  based  the  programming  environment 
on  an  existing  progamming  language.  While  this  limited  what  our  system  could  do,  it  enabled  us 
to  build  a  real  system  in  which  we  could  build  real  application  programs. 
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